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Abstract 

Transaction Memory (TM) is a concurrency control abstraction that allows the pro¬ 
grammer to specify blocks of code to be executed atomically as transactions. However, 
since transactional code can contain just about any operation attention must be paid 
to the state of shared variables at any given time. E.g., contrary to a database trans¬ 
action, if a TM transaction reads a stale valne it may execnte dangerous operations, 
like attempt to divide by zero, access an illegal memory address, or enter an infinite 
loop. Thns serializability is insufficient, and stronger safety properties are required in 
TM, which regulate what values can be read, even by transactions that abort. Hence, 
a number of TM safety properties were developed, including opacity, and TMSl and 
TMS2. However, such strong properties preclude using early release as a technique 
for optimizing TM, because they virtually forbid reading from live transactions. On 
the other hand, properties that do allow early release are either not strong enough to 
prevent any of the problems mentioned above (recoverability), or add additional con¬ 
ditions on transactions with early release that limit their applicability (elastic opacity, 
live opacity, virtual world consistency). This paper introduces last-use opacity, a new 
TM safety property that is meant to be a compromise between strong properties like 
opacity and serializability. The property eliminates all but a small class of inconsistent 
views and poses no stringent conditions on transactions. For illustration, we present a 
last-use opaque TM algorithm and show that it satisfies the new safety property. 


1 Introduction 

Writing concurrent programs using the low-level synchronization primitives is notoriously 
difficult and error-prone. Over the past decade, there has been a growing interest in alterna¬ 
tives to lock-based synchronization by turning to the idea of software transactional memory 
(TM) [3ni HSl . Basically, TM transplants the transaction abstraction from database systems 
and uses it to hide the details of synchronization. In particular, TM uses speculative exe¬ 
cution to ensure that transactions in danger of reading inconsistent state abort and retry. 
This is a fairly universal solution and means that the programmer must only specify where 
transactions begin and end, and TM manages the execution so that the transactional code 
executes correctly and efficiently. Thus, the programmer avoids having to solve the prob¬ 
lem of synchronization herself, and can rely on any one of a plethora of TM systems (e.g., 

[lainiiiiiiiiiiMiEz]). 
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Since TM allows transactional code to be mixed with non-transactional code and to 
contain virtually any operation, rather than just reads and writes like in its database prede¬ 
cessors, greater attention must be paid to the state of shared variables at any given time. For 
instance, if a database transaction reads a stale value, it must simply abort and retry, and 
no harm is done. Whereas, if a TM transaction reads a stale value it may execute an unan¬ 
ticipated dangerous operation, like dividing by zero, accessing an illegal memory address, 
or entering an infinite loop. Thus, TM systems must restrict the ability of transactions to 
view inconsistent state. 

To that end, the safety property called opacity dulls] was introduced, which includes 
the condition that transactions do not read values written by other live (not completed) 
transactions alongside serializability |25| and real-time order conditions. Opacity became the 
gold standard of TM safety properties, and most TM systems found in the literature are, in 
fact, opaque. However opacity precludes early release, an important programming technique, 
where two transactions technically conflict but nevertheless both commit correctly, and 
still produce a history that is intuitively correct. Systems employing early release (e.g. 
in m [n I isD) show that this yields a significant and worthwhile performance benefit. 
This is particularly (but not exclusively) true with pessimistic concurrency control, where 
early release is vital to increased parallelism between transactions, and therefore essential 
for achieving high efficiency in applications with high contention. 

Since opacity is a very restrictive property, a number of more relaxed properties were in¬ 
troduced that tweaked opacity’s various aspects to achieve a more practical property. These 
properties include virtual world consistency (VWC) |21j . transactional memory specification 
(TMSl and TMS2) [TT], elastic opacity m, and live opacity m- The first contribution of 
this paper is to examine these properties and determine whether or not they allow the use 
of early release in TM, and, if so, what compromises they make with respect to consistency, 
and what additional assumptions they require. We then consider the applicability of these 
properties to TM systems that rely on early release. In addition to TM properties, we sim¬ 
ilarly examine common database consistency conditions: serializability [25) . recoverability 
[TO] , avoiding cascading aborts (ACA) [7] , strictness [7], and rigorousness [3]. 

The second contribution of this paper is to introduce a new TM safety property called 
last-use opacity that allows early release without requiring stringent assumptions but nev¬ 
ertheless eliminates inconsistent views or restricts them to a manageable minimum. We 
give a formal definition, discuss example last-use opaque histories, and compare the new 
property with existing TM properties, specifically showing that it is stronger than serializ¬ 
ability but weaker than opacity. We also describe the guarantees given by last-use opacity 
and consider the applicability of the property in system models that either allow, deny, or 
restrict the explicit programmatic abort operation. Whereas, last-use opacity eliminates 
inconsistent views in system models that forbid explicitly aborting transactions or restricts 
this to particular scenarios, we show that allowing free use of explicit aborts can lead to 
inconsistent views in last-use opaque histories. Thus, we also introduce a stronger variant 
of the property called /3-last-use opacity that precludes them. 

Finally, we give SVA [34], a TM concurrency control algorithm with early release and 
demonstrate that it satisfies last-use opacity. 

The paper is structured as follows. We present the definitions of basic terms in Section]^ 
We follow by an examination of the TM property space in Section]^ Next, we define and 
discuss last-use opacity in Section]^ Then, we present SVA and demonstrate its correctness 
in Section]^ Finally, we present the related work in Section]^ and conclude in Section]^ 
We also include an appendix containing additional proofs. 
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2 Preliminaries 


Before discussing properties and their relation to early release, let us provide definitions of 
the relevant ancillary concepts. 

Let n = {pi,p 2 , ■■■,Pn} be a set of processes. Then, let program P be defined as a set 
of subprograms P = {"Pi, 7^2, ■■■,'Pn} such that for each process pk in 11 there is exactly one 
corresponding subprogram Vk in P and vice versa. Each subprogram e P is a finite 
sequence of statements in some language L. The definition of L can be whatsoever, as long 
as it provides constructs to execute operations on shared variables in accordance with the 
interface and assumptions described further in this section. In particular, L can allow local 
computations whose effects are not visible outside a single processes. 

Given program P and a set of processes 11, we denote an execution of P by 11 as £(P, H). 
An execution entails each process pfe G 11 evaluating some prefix of subprogram Vk e P- The 
evaluation of each statement by a process is deterministic and follows the semantics of L. 
£1(P, n) is concurrent, i.e. while the statements in subprogram Vk are evaluated sequentially 
by a single process, the evaluation of statements by different processes can be arbitrarily 
interleaved. We call f(P,n) a complete execution if each process pk in 11 evaluates all of 
the statements in Vk- Otherwise, we call £(P, 11) a partial execution. 

Variables Let V be a set of shared variables (or variables, in short). Each variable, 
denoted as x,y,z etc., supports the following operations, denoted o, that allow to retrieve 
or modify its state: 

a) write operation w{x)v that sets the state of x to value v, the operation’s return value 
is the constant ok, 

b) read operation r(x) whose return value is the current state of x. 

In order to execute some operation o on variable x, process pk issues an invocation event 
denoted inv^{o), and receives a response event denoted res^{u), where u is the return value 
of o. The pair of these events is called a complete operation execution and it is denoted 
o* —> u, whereas an invocation event inv^{o) without the corresponding response event is 
called a pending operation execution. Specifically, a complete execution of a read operation 
by process pk is denoted r^{x) —> v and a complete execution of a write operation is 
denoted w^{x)v —> ok. We refer to complete and pending operation executions as operation 
executions, denoted by op. 

Each event is atomic and instantaneous, but the execution of the entire operation com¬ 
posed of two events is not. 

Transactions Transactional memory (TM) is a programming paradigm that uses transac¬ 
tions to control concurrent execution of operations on shared variables by parallel processes. 
A transaction G T is some piece of code executed by process pk, as part of subprogram 
Vk- Hence, we say that pk executes V. Process pk can execute local computations as well 
as operations on shared variables as part of the transaction. In particular, the processes can 
execute the following operations as part of transaction Tp. 

a) starti which initializes transaction V, and whose return value is the constant oki, 

b) Wi{x)v and ri{x) which respectively write a value v to variable x and read x within 
transaction V, and return either the operation’s return value or the constant Ai, 
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c) tryC^ which attempts to commit Ti and returns either the constant Ci or the constant 

There is also another operation allowed in some TM systems and not in others, and we wish 
to discuss it separately. Namely, some TMs allow for a transaction to programmatically roll 
back by executing the operation: 

d) tryA^ which aborts Ti and returns Ai. 

The constant Ai indicates that transaction Ti has been aborted, as opposed to the constant 
Ci which signifies a successful commitment of the transaction. 

By analogy to processes executing operations on variables, if process pk executes some 
operation as part of transaction Ti it issues an invocation event of the form inVi{starti), 
inVi{o) for some x, or inv^{tryCi), (or possibly inv^{tryAi)) and receives a response of 
the form res^{ui), where iti is a value, or the constant oki, Ci, or Ai. The superscript 
always denotes which process executes the operation, and the subscript denotes of which 
transaction the operation is a part. We denote operation executions by process pk within 
transaction Ti as: 

a) starti oki, 

b) rj^i^x) ^ V or r^{x) Ai, 

c) 'Wi{x)v —> oki or Wi{x)v —> Ai, 

d) tryC^ Ci or tryC’l Ai. 

e) tryA^ A,. 

TM assumes that processes execute operations on shared variables only as part of a 
transaction. Furthermore, we assume that any transaction Ti is executed by exactly one 
process pk and that each process executes transactions sequentially. 

Even though transactions are subprograms evaluated by processes, it is convenient to talk 
about them as separate and independent entities. Thus, rather than saying executes some 
operation as part of transaction Ti, we will simply say that Ti executes (or performs) some 
operation. Hence we will also forgo the distinction of processes in transactional operation 
executions, and write simply: starti oki, ri{x) —> v, Wi{x)v —> oki, t^yCi —> Ci, etc. By 
analogy, we also drop the superscript indicating processes in the notation of invocation and 
response events, unless the distinction is needed. 

Sequential Specification Given variable x, let sequential .specification of x, denoted 
Seq{x), be a prefix-closed set of sequences containing invocation events and response events 
which specify the semantics of shared variables. (A set Q of sequences is prefix-closed if, 
whenever a sequence S' is in Q, every prefix of S is also in Q.) Intuitively, a sequential 
specification enumerates all possible correct sequences of operations that can be performed 
on a variable in a sequential execution. Specifically, given D, the domain of variable x, 
and Vq e D, an initial state of x, we denote by Seq{x) the sequential specification of x 
s.t., Seq{x) is a set of sequences of the form [ai Vi,a2 —> V2, ■■■,ocm I'm], where each 
aj —> Vj (j = l..m) is either: 

a) Wi{x)vj —> oki, where vj e D, or 
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b) ri(x) —>■ Vj, and either the most recent preceding write operation is wi{x)vj oki (I < i) 

or there are no preceding writes and Vj = vq. 

From this point on we assume that the domain D of all transactional variables is the set 
of natural numbers No and that the initial value vq of each variable is 0 . 

Even though we describe the interface and sequential specification of variables to rep¬ 
resent the behavior of registers, we do so out of convenience and our conclusions can be 
trivially extended to other types of objects e.g. compare and swap objects or stacks. 

Histories A TM history iJ is a sequence of invocation and response events issued by 
the execution of transactions Th = {Fi, 72 , Tt}. The occurrence and order of events 
in H is dictated by a given (possibly partial) execution of some program P by processes 
n. We denote hy H \= £1(P,If) that history H is produced by £1(P, 11). Note, that different 
interleavings of processes in i£(P, 11 ) can produce different histories. A subhistory of a history 
H is a subsequence of H. 

The sequence of events in a history Hj can be denoted as Hj = [ei, 62 ,..., em]. For 
instance, some history Hi below is a history of a run of some program that executes trans¬ 
actions Ti and T 2 '. 

Hi = [ invi{starti), resi{oki), inv 2 {start 2 ), res 2 {ok 2 ), 

invi{wi{x)v), inv2{r2{x)), reSi{oki), res2{v), 
invi{tryCi), resi{Ci), inv2{tryC 2 ), res2{C2) ]• 

Given any history i7, let H\Ti be the longest subhistory of H consisting only of invoca¬ 
tions and responses executed by transaction Ti. For example, Hi\T 2 is dehned as: 

Hi\T2 = [ inv2{start2),res2{ok2),inv2{r2{x)),res2{v),inv2{tryC2),rss2{C2) ]• 

We say transaction Ti is in H, which we denote Ti e H, if H\Ti 7 ^ 0 . 

Let H\pk be the longest subhistory of H consisting only of invocations and responses 
executed by process pk- 

Let H\x be the longest subhistory of H consisting only of invocations and responses 
executed on variable x, but only those that form complete operation executions. 

Given complete operation execution op that consists of an invocation event e' and a 
response event e", we say op is in H {op e H) if e' e iJ and e" G H. Given a pending 
operation execution op consisting of an invocation e', we say op is in H {op e H) ii e' e H 
and there is no other operation execution op' consisting of an invocation event e' and a 
response event e" s.t. op' G H. 

Given two complete operation executions op' and op" in some history H, where op' 
contains the response event res' and op" contains the invocation event inv" ^ we say op' 
precedes op" in H if res' precedes inv" in H. 

A history whose all operation executions are complete is a complete history. 

Most of the time it will be convenient to denote any two adjoining events in a history 
that represent the invocation and response of a complete execution of an operation as that 
operation execution, using the syntax e —> e'. Then, an alternative representation of Hi\T 2 
is denoted as follows: 

Hi\T 2 = [ start 2 ok 2 , r 2 {x) —> v, tryC 2 —> C 2 ]. 

History H is well-formed if, for every transaction Ti in H, H\Ti is an alternating sequence 
of invocations and responses s.t.. 
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a) H\Ti starts with an invocation inv^{starti), 

b) no events in H\Ti follow res^{Ci) or res^{Ai), 

c) no invocation event in H\Ti follows inv^{tryCj) or inv^{tryAj), 

d) for any two transactions Ti and Tj s.t., Ti and Tj are executed by the same process pk, 
the last event of H\Ti precedes the first event of H\Tj in H or vice versa. 

In the remainder of the paper we assume that all histories are well-formed. 

History Completion Given history H and transaction Ti, Ti is committed if H\Ti con¬ 
tains operation execution tryCi —> Ci. Transaction Ti is aborted if H\Ti contains response 
reSi{Ai) to any invocation. Transaction Ti is commit-pending if H\Ti contains invocation 
tryCi but it does not contain reSj(^i) nor reSi{Ci). Finally, Ti is live if it is neither com¬ 
mitted, aborted, nor commit-pending. 

Given two histories H' = [e'l, e^,..., e^] and H" = [e", e^,..., e^], we define their con¬ 
catenation as H' ■ H" = [e'l, 63 ,..., e^, e", 63 ,..., e^]. We say P is a prefix oi H ii H = P ■ H'. 

Then, let a completion Compl{H) of history H be any complete history s.t., H is a prefix 

of Compl{H) and for every transaction Ti e H subhistory Compl{H)\Ti equals one of the 
following: 

a) H\Ti, ii Ti finished committing or aborting, 

b) T[\Ti ■ [reSj(Gi)], if Ti is live and contains a pending tryCi, 

c) T[\Ti ■ [reSi{Ai)], if Ti is live and contains some pending operation, 

d) H\Ti ■ [tryCi ^* 1 ) if i® contains no pending operations. 

Note that, if all transactions in H are committed or aborted then Compl{H) and H are 
identical. 

Two histories H' and H" are equivalent (denoted TT = H") if for every e T it is true 
that H'\Ti = H"\Ti. When we write TT is equivalent to H" we mean that TT and H" are 
equivalent. 

Sequential and Legal Histories A real-time order <h is an order over history H s.t., 
given two transactions Ti,Tj e H, if the last event in H\Ti precedes in H the hrst event 
of H\Tj, then Ti precedes Tj in H, denoted Ti <h Tj. We then say that two transactions 
Ti,Tj G H are concurrent if neither Ti <h Tj nor Tj <h Ti. We say that history TT 
preserves the real-time order of H if <h'=<H'- A sequential history S' is a history, s.t. 
no two transactions in S are concurrent in S. Some sequential history S is a sequential 
extension of if S is equivalent to H and S preserves the real time order of H. 

We analogously define a real-time order <h of operation executions over history H. 

Let S' be a sequential history that only contains committed transactions, with the pos¬ 
sible exception of the last transaction, which can be aborted. We say that sequential history 
S' is legal if for every x eY, S'\x e Seq{x). 

Using the definitions above allows us to formulate the central concept that defines con¬ 
sistency in opacity: transaction legality. Intuitively, we can say a transaction is legal in a 
sequential history if it only reads values of variables that were written by committed trans¬ 
actions or by itself. More formally, given a sequential history S and a transaction Ti G S, 
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we then say that transaction is legal in S if Vis{S,Ti) is legal, where Vis{S,Ti) is the 
longest subhistory S' of S s.t., for every transaction Tj e S', either i = j or Tj is committed 
in S' and Tj <s Ti. 

Unique Writes History H has unique writes if, given transactions Ti and Tj (where i ¥= j 
or i = j), for any two write operation executions Wi{x)v' oki and Wj{x)v" okj it is 
true that v' ¥= v" and neither v' = vq nor v" = vq. 

For the remainder of the paper we focus exclusively on histories with unique writes. This 
assumption does not reduce generality, in that any history without unique writes trivially can 
be transformed into a history with unique writes (for instance, by appending a timestamp 
to each written value). 

Accesses Given a history H and a transaction Ti in H, we say that Ti reads variable x 
in H if there exists an invocation inVi{ri{x)) in H\Ti. By analogy, we say that Ti writes 
to X in iJ if there exists an invocation inVi{wi(x)v) in H\Ti. If Ti reads x or writes to x 
in H, we say Ti accesses x in H. In addition, let T^’s read set be a set that contains every 
variable x, s.t. Ti reads x. By analogy, T^’s write set contains every x, s.t. Ti writes to x. 
A transaction’s access set, denoted ASet(Ti), is the union of its read set and its write set. 

Given a history H and a pair of transactions Ti,Tj e H, we say Ti and Tj conflict on 
variable x in i/ if Ti and Tj are concurrent, both Ti and Tj access x, and one or both of Ti 
and Tj write to x. 

Given a history H (with unique writes) and a pair of transactions Ti, Tj G H , we say Ti 
reads from Tj if there is some variable x, for which there is a complete operation execution 
Wj{x)v — > okj in H\Tj and another complete operation execution ri{x) —> u in H\Ti, s.t. 
V = u. 

Given any transaction Ti in some history H (with unique writes) any operation execution 
on a variable x within H\Ti is either local or non-local. Read operation execution ri(x) —> v 
in H\Ti is local if it is preceded in H\Ti by a write operation execution on x, and it is non¬ 
local otherwise. Write operation execution Wi{x)v —>■ oki in T[\Ti is local if it is followed in 
H\Ti by an invocation of a write operation on x, and non-local otherwise. 

Safety Properties A property fp is a condition that stipulates correct behavior. In 
relation to histories, a given history satisfies fp if the condition is met for that history. In 
relation to programs, program P satisfies fp if all histories produced by P satisfy *p. 

Safety properties [53] are properties which guarantee that ’’something [bad] will not 
happen.” In the case of TM this means that, transactions will not observe concurrency 
of other transactions. Property ^ is a safety property if it meets the following definition 
(adapted from |5]): 

Definition 1 . A property fp js o safety property if, given the set IHqj of all histories that 
satisfy *p.- 

a) Prefix-closure.' every prefix H' of a history H G IHIsp is also in IHItp, 

b) Limit-closure.' for any infinite sequence of finite histories Hq,Hi,..., s.t. for every 
Hh e Hqj and Hh is a prefix of Hh+i, the infinite history that is the limit of the sequence 
is also in IHIqj. 

For distinction, in the remainder of the paper we refer to properties that are not safety 
properties as consistency conditions. 
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3 Early Release 

In this section we discuss whether existing safety properties and consistency conditions allow 
for early release (extending our work in |3dj 1 and to what extent. The aim of the analysis is 
to find properties that describe the guarantees of TM systems with early release that can be 
applied in practice. That is, we seek a safety property that allows early release but reduces 
or eliminates undesired behaviors. 

Early release pertains to a situation where conflicting transactions execute partially in 
parallel while accessing the same variable. The implied intent is for all such transactions 
to access these variables without losing consistency and thus for them all to finally commit. 
We define the concept of early release as follows: 

Definition 2 (Early Release). Given history H (with unique writes), transaetion Ti e H 
releases variable x early in H iff there is some prefix P of H, such that is live in P and 
there exists some transaetion Tj e P such that there is a complete non-local read operation 
execution opj = rffx) v in P\Tj and a write operation execution op^ = Wi{x)v oki in 
P\Ti such that op^ precedes op^ in P. 

We begin our analysis by defining its key questions. The first and the most obvious is 
whether a particular property supports early release at all. This is defined as follows: 

Definition 3 (Early Release Support). Property tp supports early release iff given some 
history H that satisfies tp there exists some transaction e H, s.t. releases some 
variable x early in H. 

If a property allows early release, it allows a significant performance boost (e.g. [HE]) 
as transactions are executed with a higher degree of parallelism. However, early release 
can give rise to some unwanted or unintuitive scenarios with respect to consistency. The 
most egregious of these is overwriting, where one transaction releases some variable early, 
but proceeds to modify it afterward. In that case, any transaction that started executing 
operations on the released variable will observe an intermediate value with respect to the 
execution of the other transaction, ie., view inconsistent state. 

An example of overwriting is shown in Fig. [^ where transaction releases variable x 
early but continues to write to x afterward. As a consequence, Tj first reads the value of x 
that is later modified. When Tj detects it is in conflict while executing a write operation it 
is aborted. This is a way for the TM to attempt to mitigate the consequences of viewing 
inconsistent state. The transaction is then restarted as a new transaction Tj/. 

However, as argued in |15j . simply aborting a transaction that views inconsistent state 
is not enough, since the transaction can potentially act in an unpredictable way on the 
basis of using an inconsistent value to perform local operations. For instance, if the value is 
used in pointer arithmetic it is possible for the transaction to access an unexpected memory 
location and crash the process. Alternatively, if the transaction uses the value within a loop 
condition, it can enter an infinite loop and become parasitic. 

Thus, in our analysis of existing properties we ask the question whether, apart from 
allowing early release, the properties also forbid overwriting. In the light of the potential 
dangerous behaviors that can be caused by it, we consider properties that allow overwriting 
to be too weak to be practical. 

Definition 4 (Overwriting Support). Property‘s supports overwriting iffS supports early 
release, and given some history H (with early release) that satisfies S> foi" some pair of 
transactions Ti,Tj e H s.t., 
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Figure 1: History with early release and overwriting. The diagram depicts some history 
H presented as operations executed by transactions on a time axis. Every line depicts the 
operations executed by a particular transaction, e.g., the line marked depicts subhistory 
H\Ti. The symbol —denotes a complete operation execution (an invocation event imme¬ 
diately followed by a response event). For brevity, whenever the response event of some 
operation execution is oki we omit it, eg., we write Wi(a;)l rather than Wi(x)l—» oki. We 
also shorten the representation of complete read operation executions, so that eg. rj{x) 1 
is represented as rj{x)l. The arrow ^''^is used to emphasize a happens before relation, and 
denotes that the preceding transaction aborts (here, Tj) and a new transaction (Tji) 
is spawned. 


starti Wi{x)l tryAi^Ai 



Figure 2: History with early release and cascading abort. 


a) Ti releases some variable x early, 

b) H\Ti contains two write operation executions: Wi{x)v oki o,nd Wi{x)v' oki, s.t. 

the former precedes the latter in H\Ti, 

c) H\Tj contains a read operation execution rj{x) v that precedes Wi(x)v' —> oki in H. 

In addition, we look at whether or not a particular property forbids a transaction that 
releases some variable early to abort. This is a precaution taken by many properties to 
prevent cascading aborts, another type of scenario leading to inconsistent views. An example 
of this is shown in Fig. In such a case a transaction, here Ti, releases a variable early and 
subsequently aborts. This can cause another transaction Tj that executed operations on 
that variable in the meantime to observe inconsistent state. In order to maintain consistency, 
a TM will then typically force Tj to abort and restart as a result. 

However, while the condition that no transaction that releases early can abort, solves the 
problem of cascading aborts, it significantly limits the usefulness of any TM that satisfies 
it, since TM systems typically cannot predict whether any particular transaction eventu¬ 
ally commits or aborts. In particular, there are important applications for TM, where a 
transaction can arbitrarily and uncontrollably abort at any time. Such applications include 
distributed TM and hardware TM, where aborts can be caused by outside stimuli, such as 
machine crashes. 

An exception to this may be found in systems making special provisions to ensure that 
irrevocable transactions eventually commit (see e.g., m)- In such systems, early release 
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Figure 3: History with an aborting early release transaction. 


transactions could be ensured never to abort. However, case in point, these take drastic 
measures to ensure that, e.g., at most a single irrevocable transaction is present in the 
system at one time. Therefore, the requirement may be difficult to enforce. 

Finally, the requirement that transactions which released early must not abort precludes 
some scenarios that are intuitively correct. For instance, take the example in Fig. Here, 
Ti writes 1 to cc and releases it early. Tj reads 1 from x and then aborts by executing the 
tryA operation, which also causes Ti to abort. Since Tj reads from Ti while the latter is 
live, Ti releases early in this history. Then, if there is a requirement that transactions which 
release early not abort, then this history is an incorrect one. However, since Tj aborted on 
its own accord, there are no transactions that would be affected by Ti aborting later on. 
Hence, intuitively, the history is actually correct. Thus, we consider the requirement that 
transactions which release early must not abort to be overstrict. 

Hence, we seek properties that allow aborts in transactions that release early. 

Definition 5 (Aborting Early Release Support). Property^ supports aborting early release 
iff'V supports early release, and given some history H that satisfies fp, for some transaetion 
Ti B H that releases some variable x early, H\Ti contains Ai. 

The properties under consideration are the typical TM safety properties: serializability, 
opacity, transactional memory specification, virtual world consistency, and elastic opacity. 
Furthermore, we examine some of the family of live properties from |12| . since this recent 
work introduces a number of relaxed versions of TM safety properties with the view of 
accommodating early release. Finally, we consider some strong database consistency con¬ 
ditions that pertain to transactional processing: recoverability, avoiding cascading aborts, 
strictness, and rigorousness. 

3.1 Serializability 

The first property we consider is serializability, which can be regarded as a baseline TM 
safety property. It is defined in |25j in three variants: conflict serializability, view serial¬ 
izability, and final-state serializability. We follow a more general version of serializability 
defined in [36] (as global atomicity), which we adjust to account for non-atomicity of commits 
in our model. 

Definition 6 (Serializability). History H is serializable iff there exists some sequential 
history S equivalent to a completion CompfiH) sueh that any committed transaction in S 
is legal in S. 

This definition does not preclude early release, as long as illegal transactions are aborted. 
Serializability also permits overwriting and cascading aborts. 
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Theorem 1. Serializahility supports early release. 

Proof. Let iJ be a transactional history as shown in Fig. Note that since all transactions 
in H are committed or aborted then H = Compl{H). Then, let there be a sequential history 
S = H\Ti ■ H\Tj ■ H\Tji. Note that S = H. Trivially, all the committed transactions in S, 
i.e. Ti and Tj, are legal in S, so H is serializable. Since, by Def. Ti releases early in iL, 
then, by Def. serializahility supports early release. □ 

Theorem 2. Serializahility supports overwriting. 

Proof. Let iJ be a serializable history as in the proof of Theorem above. Transaction 
writes 1 to x in prior to Tj reading 1 from x, and subsequently writes 2 to x. Thus, 
according to Def. serializahility supports overwriting. □ 

Theorem 3. Serializahility supports aborting early release. 

Proof. Let H hea history such as the one in Fig.[^ Since all transactions in H are committed 
or aborted then H = Compl{p[). Then, let S' be a sequential history equivalent to H such 
that S = H\Ti ■ H\Tj ■ H\Tji. S contains only one committed transaction Tj>, which is 
trivially legal in S. Thus P[ is serializable. In addition, transaction in S both releases x 
early (Def. and contains an abort (A^ e H\Ti). Thus, by Def. serializahility supports 
aborting early release. □ 

3.2 Opacity 

Opacity [HUS] can be considered the standard TM safety property that guarantees seri- 
alizability and preservation of real-time order, and prevents reading from live transactions. 
It is defined by the following two definitions. The first definition specifies final state opacity 
that ensures the appropriate guarantees for a complete transactional history. The second 
definition uses final state opacity to define a safety property that is prefix closed. Both 
definitions follow those in |I5| . 

Definition 7 (Final state opacity). A finite TM history P[ is final-state opaque if, and only 
if, there exists a sequential history S equivalent to any completion of P[ s.t, 

(a) S preserves the real-time order of H, 

(h) every transaction Ti in S is legal in S. 

Definition 8 (Opacity). A TM history H is opaque if, and only if, every finite prefix of H 
is final-state opaque. 

Theorem 4. Opacity does not support early release. 

Proof. By contradiction let us assume that opacity supports early release. Then, from 
Def. 1^ there exists some history H (with unique writes), s.t. H is opaque and there exists 
some transaction Ti e H that releases some variable x early in H. 

From Def. this implies that there exists some prefix P of H s.t. 

a) there is an operation execution opi = Wi{x)v oki and op, e P\Ti, 

b) there exists a transaction Tj e P {i ^ j) and an operation execution opj = rj{x) v, 
s.t. opj e P\Tj and opi precedes opj in P, 
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c) Ti is live in P. 


Let Pc be any completion of P. Since Tj is live in P, by definition of completion, it is 
necessarily aborted in Pc (ie. Ai e Pc\Ti). Given any sequential history S equivalent to 
Pc, since Ti is aborted in Pc and Vis{S,Tj) only contains operations of committed transac¬ 
tions, then Pc\Ti $ Vis{S,Tj). This means that opj e Vis{S,Tj) but opi ^ Vis{S,Tj), so 
Vis{S,Tj) $ Seq{x) and therefore Vis{S,Tj) is not legal. 

On the other hand, Def. [^implies that any prefix P of iL is final state opaque, which, by 
Def. implies that there exists some completion Pc of P for which there exists an equivalent 
sequential history S s.t., any Tj in S is legal in S. Since any Tj is legal then for any Tj, 
Vis{S,Tj) is legal. This is a contradiction with the paragraph above. Thus, there cannot 
exist a history like H that is both opaque and contains a transaction that releases some 
variable early. □ 

Since both Def. and Def. [^ require early release support, then: 

Corollary 1. Opacity does not support overwriting. 

Corollary 2. Opacity does not support aborting early release. 

3.3 TMSl and TMS2 

In m the authors argue that some scenarios, such as sharing variables between transactional 
and non-transactional code, require additional safety properties. Thus, they propose and 
rigorously define two consistency conditions for TM: transactional memory specification 1 
(TMSl) and transactional memory specification 2 (TMS2). 

TMSl follows a set of design principles including a requirement for observing consistent 
behavior that can be justified by some serialization. Among others, TMSl also requires 
that partial effects of transactions are hidden from other transactions. These principles are 
reflected in the definition of the TMSl automaton, and we paraphrase the relevant parts of 
the condition for the correctness of an operation’s response in the following definitions (see 
the definitions of extConsPrefix and validResp for TMSl in m)- 

Given a history H and some response event r in H, let LTfr denote a subhistory of H 
s.t. for every operation execution op B H, op B H\r iff op <h r and op is complete. This 
represents all operations executed ,,thus far,” when considering the legality of r. 

Let T'jj be the set of all transactions in H s.t. Tk B iS Tk B H and invi,{tryCf.) B 
H\Tk. Given response event r, let be the set of all transactions in H s.t. Tk B T^'fr 

if Tk B and inVk{tryCk) <h t. These sets represent transactions which committed or 
aborted (but are not live) and the set of all such transactions that did so before response 
event r. 

Given some history H, let by any subset of transactions in H. Let cr be a sequence of 
transactions. Let ser(T^, <h) be a set of all sequences of transactions s.t. a B ser(T'^, <b) 
if cr contains every element of exactly once and for any Ti, Tj B T^, if Ti <h Tj then Ti 
precedes Tj in cr. 

Given a history H and some response event r in H, let ops{a, r) be a sequence of operations 
s.t. if CT = [Ti, T 2 ,..., T„] then ops{a,r) = H\r\Ti ■ H\r\T 2 ■ ... • H\r\Tn. This represents 
the sequential history prior to response event r that respects a specific order of transactions 
defined by a. 

The most relevant condition in TMSl with respect to early release checks the validity 
of individual response operations. A prequisite for checking validity is to check whether 
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a response event can be justified by some externally consistent prefix. This prefix consists 
of operations from all transactions that precede the response event and whose effects are 
visible to other transactions. Specifically, if a transaction precedes another transaction in 
the real time order, then it must be both committed and included in the prefix, or both 
not committed and excluded from the prefix. However, if a transaction does not precede 
another transaction, it can be in the prefix regardless of whether it committed or aborted. 

Definition 9 (Extended Consistent Prefix). Given a history H and a response event r, let 
the set of transactions be any subset of all transactions in H s.t. for any Ti, Tj e if 
Ti <H Tj then Ti is in iff resfiCi) e H^rlTi. 

TMSl specifies that each response to an operation invocation in a safe history must be 
valid. Intuitively, a valid response event is one for which there exists a sequential prefix that 
is both legal and meets the conditions of an externally consistent prefix. More precisely, the 
following condition must be met. 


Definition 10 (Valid Response). Given a transaction Ti in H, we say the response r to some 
operation invocation e is valid if there exists set and sequence a G ser(T^, <h) 

s.t. satisfies Def. and ops{a ■ Ti, r) • [e ^ r] is legal. 

Theorem 5. TMSl does not support early release. 


Proof. Assume by contradiction that TMSl supports early release. Then by Def. there 
exists some TMSl history H s.t. Ti,Tj G H and there is a prefix P oi H s.t. opi = 
Wi{x)v oki G P\Ti, opj = rj{x) v e P\Tj, and Ti is live in H. This implies that 
invfitryGi) f P\reSj{v)\Ti. This means that Ti f and therefore not in any T' c or, 
by extension, any cr G seriT', <h)- Therefore, there is no opi in ops{a, reSj{v)), so, assuming 


unique writes, opj is not preceded by a write of ?; to a; in ops{cr ■ Tj, reSj(v)) ■ [rj{x) 
Therefore, ops{a ■ Tj, resAv)) • \rj{x) —> w] is not legal, which contradicts Def. 
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v]. 

□ 


Since both Def. and Def. [^ require early release support, then: 


Corollary 3. TMSl does not support overwriting. 


Corollary 4. TMSl does not support aborting early release. 

TMS2 is a stricter, but more intuitive version of TMSl. Since the authors show in m 
that TMS2 is strictly stronger than TMSl (TMS2 implements TMSl), the conclusions above 
equally apply to TMS2. Hence, from Theorem 

Corollary 5. TMS2 does not support early release. 

Corollary 6. TMS2 does not support overwriting. 

Corollary 7. TMS2 does not support aborting early release. 


3.4 Virtual World Consistency 

The requirements of opacity, while very important in the context of TM’s ability to execute 
any operation transactionally, can often be excessively stringent. On the other hand serial- 
izability is considered too weak for many TM applications. Thus, a weaker TM consistency 
condition called virtual world consistency {VWC) was introduced in |21| . The definition of 
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Figure 4: VWC history with early release. 


VWC depends on causal past. The causal past C{H, Ti) of some transaction Ti in some his¬ 
tory H is the set that contains and all aborted or committed transactions that precede 
in H. A causal past C{H,Ti) is legal, if for every Tj e C{H,Ti), s.t. i A j, Tj is committed 
in H. 

Definition 11 (Virtual World Consistency). History H is virtual world consistent iff all 
committed transactions are serializable and preserve real-time order, and for each aborted 
transaction there exists a linear extension of its causal past that is legal. 

This property allows a limited support for early release as follows. 

Theorem 6. VWC supports early release. 

Proof. Let H he a transactional history as shown in Fig.|^ Here, Ti performs two operations 
on X and one on y, while Tj reads x. The linear extension oi H ]s S = H\Ti ■ H\Tj wherein 
both transactions are trivially legal. Thus H is VWC. Since, by Def. Ti releases early in 
H, then, by Def. VWC supports early release. □ 

Theorem 7. VWC does not support overwriting. 

Proof. Since VWC requires that aborting transactions view a legal causal past, then if a 
transaction reading x is aborted, it must read a legal (i.e. ’’final”) value of x. Thus, let us 
consider some history H where some Ti releases x early, and some Tj reads x from Ti. 

a) If Ti writes to x after releasing it, and Tj commits, then Tj is not legal, and therefore H 
does not satisfy VWC. 

b) If Ti writes to x after releasing it, and Tj aborts, then the causal past of Tj contains Ti, 
and Tj reads an illegal (stale) value of x from Ti, so H does not satisfy VWC. 

Therefore, any history H containing Ti, such that Ti releases x early and modifies it after 
release does not satisfy VWC. Hence, by Def. VWC does not support overwriting. □ 

While VWC supports early release, there are severe limitations to this capability. That 
is, VWC does not allow a transaction that released early to subsequently abort for any 
reason. 

Theorem 8. VWC does not support aborting early release 

Proof. Given a history H that satisfies VWC and a transaction Ti e H that releases variable 
X in H, let us assume for the sake of contradiction that Ti eventually aborts. By Def. 
there is some Tj in H that reads from Ti. If Ti eventually aborts, then Tj reads from an 
aborted transaction. 

a) If Tj eventually aborts, then its causal past contains two aborted transactions {Ti and 
Tj) and is, therefore, illegal. Hence H does not satisfy VWC, which is a contradiction. 
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b) If Tj eventually commits, then the sequential witness history is also illegal. Hence H 
does not satisfy VWC, which is a contradiction. 

Therefore, if Ti eventually aborts, H does not satisfy VWC, which is a contradiction. Thus, 
since a VWC history cannot contain an abortable transaction that releases a variable early. 
Hence, by Def. VWC does not support aborting early release. □ 

VWC does not allow for transactions that release early to abort, which we consider to 
be an impractical assumption in some TM systems and an overstrict requirement in general. 

3.5 Live Opacity 

Live opacity was introduced in [T^ as part of a set of consistency conditions and safety prop¬ 
erties that were meant to regulate the ability of transactions to read from live transactions. 
The work analyzes a number of properties and for each one presents a commit oriented 
variant that forbids early release and a live variant that allows it. Here, we concentrate 
on live opacity, since it best fits alongside the other properties presented here, however our 
conclusions will apply to the remainder of live properties. 

Let H\{Ti,r) be the longest subsequence of H\Ti containing only read operation ex¬ 
ecutions (possibly pending), with the exclusion of the last read operation if its response 
event is Ai. Let H\{Ti,gr) be a subsequence of H\{Ti,r) that contains only non-local 
operation executions. Let T[ be a transaction that invokes the same transactional oper¬ 
ations as those invoked in H\{Ti,r) ■ [inv^{tryCj^)] if H\{Ti,r) 7 ^ 0 , or 0 otherwise. Let 
Tf be a transaction that invokes the same transactional operations as those invoked in 
[starti —> oki] ■ H\{Ti, gr) ■ [tryC^ —> C)] if H\{Ti, gr) 7 ^ 0 , or 0 otherwise. 

Given a history H, a transaction Ti e iL, and a complete local operation execution 
op = ri(x) —> V, we say the latter’s response event reSi{v) is legal if the last preceding write 
operation in H\Ti writes v to x. We say sequential history S justifies the serializability 
of history H when there exists a history H' that is a subsequence of H s.t. H’’ contains 
invocation and response events issued and received by transactions committed in H, and S 
is a legal history equivalent to H'. 

Definition 12 (Live Opacity). A history H is live opaque iff, there exists a sequential 
history S that preserves the real time order of H and justifies that H is serializable and all 
of the following hold: 

a) We can extend history S to get a sequential history S' such that: 

- for each transaction Ti s H s.t. Ti ^ S, Tf" e S', 

- if < is a partial order induced by the real time order of S in such a way that for each 
transaction Ti e H s.t. Ti ^ S we replace each instance ofTi in the set of pairs of the 
real time order of H with transaction TV, then S' respects <, 

- S’ is legal. 

b) For each transaction Ti e H s.t. Ti ^ S and for each operation op in Tf that is not in 
T®*^, the response for op is legal. 


Theorem 9. Live opacity supports early release. 
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Figure 5: Live opaque history with early release. 


Proof. Let history H be that represented in Fig. Since there is a transaction Ti e H that 
writes 1 to a; and a transaction Tj that reads 1 from x before Ti commits, then there is a 
prefix P oi H that meets Def. Therefore Ti releases x early in H. 

Let 5" be a sequential history s.t. S = H\Ti ■ H\Tj. Since the real-time order of H is 
0 , then, trivially, S preserves the real-time order of H. Since Vis{S,Ti) contains only H\Ti 
and therefore only a single write operation execution and no reads, then it is legal and Ti in 
S is legal in S. Furthermore, Vis{S, Tj) is such that Vis{S, Tj) = H\Ti ■ H\Tj and contains a 
read operation rj{x) 1 preceded by the only write operation w;i(a;)l ^ oki, so Vis{S,Tj) 
is legal, and, consequently, Tj in S is legal in S. Thus, all transactions in S are legal in S', 
so H is serializable. 


Let S' be a sequential history that extends S in accordance to Def. 12 Since there are 
no transactions in S' that are not in S, then S' = S. Thus, since every transaction in S is 
legal in S, then every transaction in S' is legal in S'. Trivially, S' also preserves the real 
time order of S. Therefore, the condition Def. [T^ is met. Since there are no local read 
operations in S, then condition Def. [T^ is trivially met as well. Therefore, H is live opaque. 

Since H is both live opaque and contains a transaction that releases early, then the 
theorem holds. □ 

Theorem 10. Live opacity does not support overwriting. 

Proof. For the sake of contradiction, let us assume that there is a history (with unique 
writes) H that is live opaque and, from Def. contains some transaction Ti that writes 
value V to some variable x and releases x early and subsequently executes another write 
operation writing v' to x where the second write follows a read operation executed by 
transaction Tj reading v from x. 

Since H is live opaque there exists a sequential history S that justifies the serializability 
of H. There cannot exist a sequential history S where Tj reads from x between two writes 
to X executed by Ti, because there cannot exist a legal Vis{S,Tj), so Tj would not be legal 
in S. Therefore, Tj must be aborted in H and therefore Tj is not in any sequential history 
S that justifies the serializability of H. 

Since Tj is in H but not in S, then given any sequential extension S' of S in accordance 
to Def. 12 Tj is replaced in S' by Tj'" which reads v from x and finally commits. However, 
since the write operation execution writing to a: in Ti is followed in S'\Ti by another write 
operation execution that writes v' to x, then there cannot exist a Vis{S',Tj'’) that is legal. 
Thus Tj'' in S' cannot be legal in S' , which contradicts Def. 12 1 . Thus, H is not live opaque, 
which is a contradiction. 

Therefore H cannot simultaneously be live opaque and contain a transaction with early 
release and overwriting. □ 


Theorem 11. Live opacity does not support aborting early release. 
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Proof. For the sake of contradiction, let us assume that there is a history (with unique 
writes) H that is live opaque and, from Def. contains some transaction Ti that writes 
value V to some variable x and releases x and subsequently aborts in H. 

Let S be any sequential history that justifies the serializability of iL, and let S' be any 
sequential extension S' of S in accordance to Def. 12 Since Ti aborts in H, then it is not 


in S, and therefore it is replaced in S' by . Since, by construction, Tf'" does not contain 
any write operation executions, there is no write operation execution writing ?; to a; in S'. 
Since Ti released x early in H there is a transaction Tj in H that executes a read operation 
reading v from x and the same read operation is in S' . But since there is no write operation 
execution writing to x in S", no transaction containing a read operation execution reading 
V from X can be legal in S' . Thus, H is not live opaque, which is a contradiction. 

Therefore H cannot be simultaneously live opaque and contain a transaction with early 
release that aborts. □ 

Like with VWC, live opacity does not allow transactions that release early to abort, 
which we consider too strict a condition. 


3.6 Elastic Opacity 

Elastic opacity is a safety property based on opacity, that was introduced to describe the 
safety guarantees of elastic transactions m- The property allows to relax the atomicity 
requirement of transactions to allow each of them to execute as a series of smaller transac¬ 
tions. An elastic transaction Ti is split into a sequence of subhistories called a cut denoted 
Ci{H), where each subhistory represents a ’’subtransaction.” In brief, a cut that contains 
more than one operation execution is well-formed if all subhistories are longer than one op¬ 
eration execution, all the write operations are in the same subhistory, and the first operation 
execution on any variable in every subhistory is not a write operation, except possibly in 
the first subhistory. A well-formed cut of some transaction Ti is consistent in some history 
H, if given any two operation executions opi and op'i on x in any subhistories of the cut, 
no transaction Tj (i i=- j) executes a write operation opj on x s.t. opi <h opj <h op'i- In 
addition, given any two operation executions opi and op'i on x, y respectively, no two trans¬ 
actions Tk^Ti [I ^ i, k ^ i) execute writes opf. on x and opi on y, s.t. opi <h opf. <h op'i 
and opi <H op I <h op'i. A cutting function fc takes a history H as an argument and 
produces a new history Hf where for each transaction Ti e H declared as elastic, Ti is 
replaced i'll Hf with the transactions resulting from the cut Ci{H) of Ti. If some transaction 
is committed (aborted) in H, then all transactions resulting from its cut are committed 
(aborted) in fc{H)- Then, elastic opacity is defined as follows: 

Definition 13 (Elastic Opacity). History H is elastic opaque iff there exists a cutting 
function fc that replaces each elastic transaction Ti in H with its consistent cutCi{H), such 
that history fc^H) is opaque. 


Theorem 12. Elastic opacity supports early release. 

Proof. Let iJ be a transactional history with unique writes as shown in Fig. Let Ti be 
an elastic transaction. Let Ci{H) be a cut of subhistory H\Ti, such that: 

Ci{H) = {[starti' ok^,, ri,{y) -» 0, w^'l^x)! -> ok^,, tryCi, C)'], 

[starti» okin, ri»(x) 1, ^//(y) ^ 0, tryCi„ Ci«]}. 
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Figure 6: Elastic opaque history with early release. 
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Figure 7: History after applying a cutting function. 


All subhistories of Ci{H) are longer than one operation, all the writes are in the first sub¬ 
history, and no subhistory starts with a write, so Ci{H) is well-formed. Since there are no 
write operations outside of Ti, then it follows that Ci{H) is a consistent cut in H. Let fc 
be any cutting function such that it cuts Ti according to Ci{H), in which case fc{H) is 
defined as in Fig.Let 5 be a sequential history s.t. S = fc{H)\Tii ■ fc{H)\Tj ■ fe{H)\Ti". 
Since T^/ precedes T^// in S as well as in fc{H), and all other transactions are not real time 
ordered, S preserves the real time order of fc{H). Trivially, each transaction in S is legal 
in S. Thus, fc{H) is opaque by Def. and in effect H is elastic opaque by Def. Since 
in H transaction Tj reads x from Ti while Ti is live, then, by Def. Ti releases x early in 
X. Hence, since H is elastic opaque, elastic opacity supports early release, by Def. □ 

Theorem 13. Elastic opacity does not support overwriting. 

Proof. For the sake of contradiction, let us assume that there is an elastic opaque history H 
s.t. transaction Ti writes value v to some variable x and releases it early in H. Furthermore, 
let us assume that there is overwriting, so after some transaction Tj reads v from x, Ti writes 
M to a;. Since only elastic transactions can release early in elastic opaque histories, and Ti 
releases early, Ti is necessarily elastic. Thus, in any fc{H) Ti is replaced by a cut Ci{H). 

The two writes on x in Ti are either a) in two different subhistories in Cnii), or b) in 
the same subhistory in Cnii). Since the definition of a consistent cut requires all writes on 
a single variable are within one subhistory of the cut, then in case (a), is inconsistent. 

Since by Def. elastic opaque histories are created using consistent cuts, then H is not 
elastic opaque, which is a contradiction. 

In the case of (b), let us say that both writes are in a subhistory that is converted into 
transaction T/ in /c(i7). Since Ti releases x early, then by Def. there is a transaction 
Tj in fc{H) which executes a read on x reading the value written by T/ in fc{H). Since 
we assume overwriting, the read operation on x in Tj reads the value written by the first 
of the two writes in Tj and does so before the other write on x is performed within Cnii)- 
Then, in any sequential history S equivalent to fc{H) either Tj <s Tj or Tj <s Tj. In the 
former case Tj in S is not legal in S', since the read on x that yields value v will not be 
preceded by any operation that writes ?; to a; in any possible Vis{S,Tj,). In the latter case 
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Tj in S is also not legal in S', since there will be a write operation writing it to a; between 
the read on x that yields value v and any operation that writes i; to a: in Vis{S,Tp). Since 
Tj in S is not legal in any S equivalent to fc{H), then, by Def. [tI fc{H) is not final-state 
opaque, and hence, by Def. not opaque. In effect, by Def. is not opaque, which is 

a contradiction. 

Thus, there cannot be an elastic opaque history H with overwriting. □ 

Theorem 14. Elastic opacity does not support early release aborting. 


Proof. For the sake of contradiction, let us assume that there is an elastic opaque history 
H s.t. transaction Ti releases some variable x early in H and aborts. Since Ti releases early 
then it writes v to x, and there is another Tj that executes a read on x that returns v before 
Ti aborts. Since only elastic transactions can release early in elastic opaque histories, and 
Ti releases early, Ti is necessarily elastic. If Ti aborts in H, then all of the transactions 
resulting from its cut Ci{H) in fc{H) also abort (by construction of fc{H)). Therefore, 
for any sequential history S equivalent to fc{H), there is no subhistory H' e Ci{H) s.t. 
H' c Vis{S,Tj), and in effect the read operation in Tj on x reading v is not preceded by a 
write operation writing v to x. Therefore, Vis{S,Tj) is illegal, so Tj in S is not legal in S', 
and thus, by Def. |^/c(iF) is not opaque. Since fc{H) is not opaque, then by Def. 13 H is 
not elastic opaque, which is a contradiction. □ 


Elastic opacity supports early release, but, since it does not guarantee serializability 
(as shown in m), we consider it to be a relatively weak property. This is contrary to our 
premise of finding a property that allows early release and provides stronger guarantees than 
serializability. Elastic transactions were proposed as an alternative to traditional transac¬ 
tions for implementing search structures, but we submit that the restrictions placed on the 
composition of elastic transactions and the need for transactions with early release to be 
non-aborting put an unnecessary burden on general-purpose TM. In particular, for a cut to 
be well-formed, it is necessary that all writes are executed in the same subtransaction, and 
that no subtransaction starts with a write, which severely limits how early release can be 
used and precludes scenarios that are nevertheless intuitively correct. In addition, elastic 
opacity requires that transactions which release early do not subsequently abort. 


3.7 Database Properties 

We follow the discussion of TM safety properties with a brief foray into database properties 
that deal with transaction consistency. Given that TM properties tend not to be very helpful 
when describing the behavior of early release, these consistency properties may be used to 
supplement that. 

Recoverability is a database property defined as below (following [16]): 

Definition 14 (Recoverability). History H is recoverable iff for any Ti,Tj e H, s.t. i j 
and Tj reads from Ti, Ti commits in H before Tj commits. 

Recoverability does not make requirements about values read by transactions, so it 
necessarily supports early release, overwriting, and aborting early release. It also allows 
histories that are not even serializable. As such, it is too weak for application in TM. 
Recoverability can be combined with serializability to restrict the order on commits and 
aborts in serializable histories. The resulting consistency condition is therefore stronger 
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than serializability. However, it still allows unrestricted early release, overwriting, and 
aborting early release, and thus is not suitable for TM. 

Avoiding cascading aborts (ACA) [7] is a database property defined as: 

Definition 15 (Avoiding Cascading Aborts). History H Avoids Cascading Aborts iff for 
any Ti,Tj e H s.t. i ^ j and Tj reads from commits before the read. 

As with recoverability, ACA restricts reading from live transactions. Therefore, ACA 
clearly removes all the scenarios encompassed by Def. Since this is the only provision of 
ACA, the property forbids early release, without giving any additional guarantees. Hence, 
it also does not support overwriting nor aborting early release. 

Strictness [7] is a database property defined as: 

Definition 16 (Strictness). History H is strict iff for any Ti,Tj e H (i ¥= j) and given any 
operation execution op^ = r^{x) v or wffx)v' —> oki in H\Ti, and any operation execution 
opj = Wj{x)v okj in H\Tj, if op^ follows opp then Tj commits or aborts before op^. 

The definition unequivocally states that a transaction cannot read from another trans¬ 
action, until the latter is committed or aborted. Thus, strictness precludes early release 
altogether. Hence, it also does not support overwriting nor aborting early release. 

Rigorousness is defined (following [^) as: 

Definition 17 (Rigorousness). History H is rigorous iff it is strict and for any Ti,Tj e H 
(i j) such that writes to variable x, i.e., op^^ = Wi{x)v oki e H\Ti after Tj reads x, 
then Tj commits or aborts before op^. 

Since in [4] the authors demonstrate that rigorous histories are opaque, and since we 
show in Theorem that opaque histories do not support early release, then neither does 
rigorousness. Hence, it also does not support overwriting nor aborting early release. 

3.8 Discussion 

The survey of properties shows that, while there are many safety properties for TM with 
a wide range of guarantees they provide, with respect to early release they fall into three 
basic groups. 

The first group consists of properties that allow early release but do not prevent overwrit¬ 
ing: serializability and recoverability. These properties do not control what can be seen by 
aborting transactions. As argued in [TS], this is insufficient for TM in general, because op¬ 
erating on inconsistent state may lead to uncontrollable errors, whose consequences include 
crashing the process. 

The second group consists of properties that preclude the dangerous situations allowed 
by the first group. This group includes opacity, TMSl, TMS2, ACA, strictness, and rigor¬ 
ousness. The properties in this group forbid early release altogether and obviously are not 
suited for TM systems that employ that mechanism. 

The third group allows early release and precludes overwriting but also precludes abort¬ 
ing in transactions that release early. It includes live opacity, elastic opacity, and VWC. 
These properties seem to provide a reasonable middle ground between allowing early re¬ 
lease and eliminating inconsistent views. However, these properties effectively require that 
transactions that release early become irrevocable. That is, once a live transaction is read 
from, it can never abort. The need to deal with irrevocable transactions is detrimental, 
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Vi. 1 transaction ■[ // spawns as T\ 

2 X = 1; 

3 if (y > 0) 

4 X = X + y; 

5 y = X + 1; 

6 } 


V2-. 1 transaction { // spawns as T 2 

2 y = y + 1; 

3 } 


Figure 8: Transactional program with closing write. 


because irrevocable transactions introduce additional complexity to a TM (see e.g., m)- 
In addition, in applications like distributed computing, transaction aborts may be induced 
by external stimuli, so it can be completely impossible to prevent transactions from abort¬ 
ing [30) . Finally, the requirement to have transactions that release early eventually commit 
unnecessarily precludes some intuitively correct histories (see Fig. [^. 

In summary, properties from the first group are not adequate for any TM and those 
from the second group do not allow any form of early release. The third group imposes 
an overstrict restriction that transactions which release early be irrevocable. None of the 
properties provide a satisfactory, strong safety property that could be used for a TM with 
early release, where aborts cannot be arbitrarily restricted. Therefore, a property expressing 
the guarantees of such systems is lacking. Hence, we introduce a property in Section]^ to 
fill this niche. 


4 Last-use Opacity 

We present last-use opacity, a new TM safety property that provides strong consistency 
guarantees and allows early release without compromising on the ability of transactions to 
abort. The property is based on the preliminary work in [32l|33]. 

The idea of last-use opacity hinges on identifying the closing write operation execution 
on a given variable in individual transactions. Informally, a closing write on some variable 
is such, that the transaction which executed it will not subsequently execute another write 
operation on the same variable in any possible extension of the history. What is possible 
is determined by the program that is being evaluated to create that history. Knowing the 
program, it is possible to infer (to an extent) what operations a particular transaction will 
execute. Hence, knowing the program, we can determine whether a particular operation on 
some variable is the last possible such operation on that variable within a given transac¬ 
tion. Thus, we can determine whether a given operation is the closing write operation in a 
transaction. 

Take, for instance, the program in Fig. where subprogram Vi spawns transaction Ti, 
and V 2 spawns T 2 . Let us assume that initially x and y are set to 0. Depending on the 
semantics of the TM, as these subprograms interweave during the execution, a number of 
histories can be produced. We can divide all of among them into two cases. In the first 
case T 2 writes 1 to y in line 2 of 7^2 and this value is then read by Ti in line 3 of T^i. As 
a consequence, Ti will execute the write operation in line 4. The second case assumes that 
Ti reads 0 in line 3 of Vi (e.g., because T 2 executed line 2 much later). In this case, Ti will 
not execute the write operation in line 4. We can see, however, that in either of the above 
cases, once Ti executes the write to x on line 4, then no further writes to x will follow in Ti 
in any conceivable history. Thus, the write operation execution generated by line 4 of Vi is 
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the closing write on x in Ti. On the other hand, the write operation execution generated by 
line 2 of Vi is never the closing write on x in Ti, because there exists a conceivable history 
where another write operation execution will appear (i.e., once line 4 is evaluated). This is 
true even in the second of the cases because line 4 can be executed in potentia, even if it is 
not executed de facto. 

Note that once any transaction Ti completes executing its closing write on some variable 
X, it is certain that no further modifications to that variable are intended by the programmer 
as part of Ti. This means, from the perspective of Ti (and assuming no other transaction 
modifies x), that the state of x would be the same at the time of the closing write as if the 
transaction attempted to commit. Hence, with respect to x, we can treat Ti as if it had 
attempted to commit. 

Last use opacity uses the concept of a closing write to dictate one transaction can read 
from another transaction. We give a formal definition in Section 4.1 but, in short, given 
any two transactions, Ti and Tj, last-use opacity allows Ti to read variable x from Tj if the 
latter is either committed or commit-pending, or, if Tj is live and it already executed its 
closing write on x. This has the benefit of allowing early release while excluding overwriting 
completely. However, last-use opacity does allow cascading aborts to occur. We discuss 
their implications in Section |4.3[ as well as ways of mitigating them. That section also 
describes the guarantees given by last-use opacity. 


4.1 Definition 

First, we define the concept of a closing write to some variable by a particular transaction. 
We do this by first defining a closing write operation invocation, and then extend the 
definition to complete operation executions. 

Given program P and a set of processes H executing P, since different interleavings of 
H cause an execution £(P, H) to produce different histories, then let be the set of all 
possible histories that can be produced by £(P, H), i.e., is the largest possible set s.t. 
IjP.n ^ I ^ f(P,n)}. 

Definition 18 (Closing Write Invocation). Given a program P, a set of processes H ex¬ 
ecuting P and a history H s.t. H ^ £(P, H), i.e. H e an invocation inVi{w{x)v) 

is the closing write invocation on some variable x by transaction Ti in H, if for any his¬ 
tory H' e for which H is a prefix (i.e., H' = H ■ R) there is no operation invocation 
inVi{w{x)u) s.t. inVi{w{x)v) precedes inVi{w{x)u) in H'\Ti. 

Definition 19 (Closing Write). Given a program P, a set of processes H executing P and 
a history H s.t. H \= £’(P, H), an operation execution is the closing write on some variable 
X by transaction Ti in H if it comprises of an invocation and a response other than Ai, and 
the invocation is the closing write invocation on x by Ti in H. 

The elosing read invocation and the closing read are defined analogously. 

If a transaction executes its closing write on some variable, we say that the transaction 
decided on x. 

Definition 20 (Transaction Decided on x). Given a program P, a set of processes H and a 
history H s.t. H ^ f(P, H), we say transaction R e H decided on variable x in H iff H\Ti 
contains a complete write operation execution Wi(x)v oki that is the closing write on x. 

Given some history H, let T'^ be a set of transactions s.t. R e iff there is some 
variable x s.t. R decided on x in H. 
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Given any Ti e H, a decided transaction subhistory, denoted H\Ti, is the longest subse¬ 
quence of H\Ti s.t.: 

a) H\Ti contains starti —» u, and 

b) for any variable x, if Ti decided on x in H, then H\Ti contains {H\Ti)\x. 

O 

In addition, a decided transaction subhistory completion, denoted H\Ti, is a sequence s.t. 
h]t, = H\T, ■ [tryC^ - Q]. 

Given a sequential history S s.t. S = H, LVis{S,Ti) is the longest subhistory of S, s.t. 
for each Tj e S: 

a) if z = j or Tj is committed in S and Tj <s Ti, then S\Tj c LVis{S,Ti), 

b) if Tj is not committed in S but Tj e and Tj <s Ti, and it is not true that Tj <h Ti, 
then either S\Tj c LVis{S,Ti) or not. 

Given a sequential history S and a transaction Ti e S, we then say that transaction Ti 
is last-use legal in S if LVis{S,Ti) is legal. Note that if S is legal, then it is also last-use 
legal (see appendix for proof). 

Definition 21 (Final-state Last-use Opacity). A finite history H is final-state last-use 
opaque if, and only if, there exists a sequential history S equivalent to any completion of H 
s.t., 

a) S preserves the real-time order of H, 

b) every transaction in S that is committed in S is legal in S, 

c) every transaction in S that is not committed in S is last-use legal in S. 

Definition 22 (Last-use Opacity). A history H is last-use opaque if, and only if, every 
finite prefix of H is final-state last-use opaque. 

Theorem 15. Last-use opacity is a safety property. 

Proof. By Def. last-use opacity is trivially prefix-closed. 

Given Hl that is an infinite limit of any sequence of finite histories Hq,Hi, ..., s.t every 
Hh in the sequence is last-use-opaque and every Hh is a prefix of Hh+i, since each prefix Hh 
of iLi is last-use-opaque, then, by extension, every prefix Hh of iJi, is also final-state last-use 
opaque, so, by Def. Hl is last-use-opaque. Hence, last-use opacity is limit-closed. 

Since last-use opacity is both prefix-closed and limit-closed, then, by Def. it is a safety 
property. □ 

4.2 Examples 

In order to aid understanding of the property we present examples of last-use opaque histo¬ 
ries in Fig. HH These are contrasted by examples of histories that are not last-use opaque 
in Fig. [T4f[T7 We discuss the examples below and prove them in the appendix. 

The example in Fig. shows Ti executing a write on x once and releasing x early to 
Tj. We assume that the program generating the history is such, that the write operation 
executed by Ti is the closing write operation execution on x. The history is intuitively 
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starti 


Wi(x)l tryCi^Ci 


T, 


start j ^rj(a:)l tryC.j 


T, 


c, 


Figure 9: Example satisfying last-use opacity: early release. We mark a closing write 
operation execution in some history in the diagram as Note that an operation can be 
the ultimate operation execution in some transaction, but still not fit the definition of a 
closing operation execution. 


starti Wi{x)l tryCi^Ci 
o---@-o 

T^ 

startj .rj{x)\ tryA.^^Aj 
o -^-o-o 

Tj 


Figure 10: Example satisfying last-use opacity: early release to an aborting transaction. 


T^ 


starti Wi{x)l tryAi^ Ai 
o-^^-o 

'V 

startj tryAj 

o-o-o 

Tj 


A, 


Figure 11: Example satisfying last-use opacity: early release between two aborting trans¬ 
actions. 


starti Wi{x)l 


tryCi ^ Ci 


T,: 


startj .rj{x)l tryAj^Aj 




Figure 12: Example satisfying last-use opacity: early release to a prematurely aborting 
transaction. 
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starti 


T, 


Wi{x)l tryAj^^Ai 
o-@-o 

start j ^ 7(^)1 

o-0-—^-@- 

Tj 

startle ^fc(^)0 
o-o- 

Tk 


Figure 13: Example satisfying last-use opacity: freedom to read from or ignore an aborted 
transaction. 


starti Wi{x)l tryC'i^Ci 



C, 


Figure 14: Example breaking last-use opacity: early release before closing write operation 
execution. 


T^ 


starti Wi{x)l tryAi^ Ai 
o -o-o 

startj rj{x)l tryA.j 
o-o-o 





Figure 15: Example breaking last-use opacity: early release between two aborting transac¬ 
tions before closing write operation execution. 

starti Wi(x)l tryC'i^C'i 

o -@———-o 

T 

startj ^ (^) 1 

o-^-o-o 

T 


Figure 16: Example breaking last-use opacity: commit order not respected. 

starti Wi{x)l Wi{x)2 tryCi^Ci 

o- 

T^ 

o 

Ty 




startj Tj (x) 1 


tryCj Cj 


Figure 17: Example breaking last-use opacity: early release with overwriting. 
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start,I 


o- 

T^ 


Wi{x)i nivU 

^- 


start j 





Wj{y)l 

- 


Figure 18: Example breaking last-use opacity: dependency cycle. 


correct, since both transactions commit, and Tj reads a value written by T^. On the formal 
side, since both transactions are committed in this history, the equivalent sequential history 
would consist of all the events in Ti followed by the events in Tj and both transactions would 
be legal, since Ti writes a legal value to x and Tj reads the last value written by Ti to x. 
Thus, the history is final-state last-use opaque. 

Since last-use opacity requires prefix closedness, then all prefixes of the history in Fig.[^ 
also need to be hnal-state last-use opaque. We present only two of the interesting prefixes, 
since the remainder are either similar or trivial. The first interesting prefix is created 
by removing the commit operation execution from Tj, which means Tj is aborted in any 
completion of the history. We show such a completion in Fig. Still, Ti writes a legal 
value to X and Tj reads the last value written by Ti to x, so that prefix is also final-state 
last-use opaque. Another interesting prefix is created by removing the commit operation 
executions from both transactions. Then, in the completion of the history both transactions 
are aborted, as in Fig. 11 Then, in an equivalent sequential history Tj would read a value 


written by an aborted transaction. In order to show legality of a committed transaction, 
we use the subhistory denoted Vis, which does not contain any transactions that were not 
committed in the history from which it was derived. Thus, if Tj were committed, it would 
not be legal, since its Vis would not contain a write operation execution writing the value 
the transaction actually read. However, since Tj is aborted, the definition of final-state last- 
use opacity only requires that LVis rather than Vis be legal, and LVis can contain operation 
executions on particular variables from an aborted transaction under the condition that the 
transaction already executed its closing write on the variables in question. Since, in the 
example Ti executed its closing write on x, then this write will be included in LVis for Tj, 
so Tj will be last-use legal. In consequence the prefix is also final-state last-use opaque. 
Indeed, all prefixes of example Fig. are final-state last-use opaque, so the example is 
last-use opaque, and, by extension, so are the examples in Fig. [^and Fig. El 

Contrast the example in Fig. with the one in Fig. The histories presented in 
both are identical, with the exception that the write operation in Fig. is considered to 
be the closing operation execution, while in Fig. it is not. The difference would stem 
from differences in the programs that produced these histories. For instance, the program 
producing the history in Fig. 14 could conditionally execute another operation on x, so, 
even though that condition was not met in this history, the potential of another write on 
X means that the existing write cannot be considered a closing write operation execution. 
The consequence of this is that while the example itself is final-state last-use opaque, one 
of its prefixes is not, so the history is not last-use opaque. The offending prefix is created 
by removing commit operations in both transactions, so both transactions would abort in 
any completion, as in Fig. [T^ Here, since Ti does not execute the closing write operation 
on X, then the write operation would not be included in LVis for Tj, so the value read by 
Tj could not be justified. Thus, Tj is not legal in that history, and, therefore, the history 
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in Fig. 15 is not final-state last-use opaque (so also not last-use opaque). Fig. 15 represents 
the completion of a prefix of the history in Fig. 14 so Fig. [^not being hnal-state last-use 
opaque, means that Fig . [T4| is not last-use opaque. 

The examples in Fig. |12| and Fig. |16[ show that recoverability is required, i.e., transactions 
must commit in order. Last-use opacity of the example in Fig. |12| is analogous to the one in 
Fig.[^ since their equivalent sequential histories are identical, as are the sequential histories 
equivalent to their prefixes. Furthermore, intuitively, if Tj reads a value of a variable released 
early by Ti and aborts before Ti commits, this is correct behavior. On the other hand, the 
history in Fig. 16 is not last-use opaque, even though it is final-state last-use opaque (by 
analogy to Fig. IF However, a prefix of the history where the commit operation execution is 
removed from Ti is not final-state last-use opaque. This is because a completion will require 
that Ti be aborted, the operations executed by Ti are not going to be included in any Vis. 
Since Tj is committed, then its Vis must be legal, but it is not, because the read operation 
reading 1 will not be preceded by any writes in Vis. Since the prefix contains an illegal 
transaction, then it is not final-state last-use opaque, and thus, the history in Fig. [^is not 
last-use opaque. 

The example in Fig. shows that a transaction is allowed to read from a transaction 
that eventually aborts, or ignore that transaction, because of the freedom left within the 
definition of LVis. I.e. transactions Tj is concurrent to T^, but Tk follows Ti in real time. Ti 
executes a closing write on x, so Tj is allowed to include the write operation on in its LVis. 
Since Tj sees the value written to x by that write, Tj includes the write in LVis. On the 
other hand, T^ cannot include T^’s write in LVis{,.,) since it aborted before Tk even started, 
so the write should not be visible to Tk. On the other hand Tk is allowed to include Tj in 
its LVis. Tk should not do so, however, since it ignores Tj as well as Ti (which makes sense 
as Tj is doomed to abort). Hence Tk reads the value of x to be 0. If Tj is included in T^’s 
LVis, reading 0 would be incorrect. Hence, the definition of LVis allows Tj to be arbitrarily 
excluded. In effect all three transactions are correct (so long as Tj does not eventually 
commit). 

Fig. shows an example of overwriting, which is not last-use opaque, since there is no 
equivalent sequential history where the write operation in Ti writing I to x would precede 
the read operation in Tj reading I from x without the other write operation writing 2 to 
X also preceding the read. Thus, in all cases Tj is not legal, and the history is neither 
final-state last-use opaque, nor last-use opaque. 

Finally, Fig. 18 shows an example of a cyclic dependency, where Tj reads x from Ti, 
and subsequently Ti reads y from Tj. Both writes in the history are closing writes. This 
example has unfinished transactions, which are thus aborted in any possible completion of 
this history. There are two possible sequential histories equivalent to that completion: one 
where Ti precedes Tj and one where Tj precedes Ti. In the former case, LVis of Ti does not 
contain any operations from Tj, because Tj follows Ti. Thus, there is no write operation on 
y preceding a read on y returning 1 in T^’s LVis, which does not conform to the sequential 
specification, so T^’s LVis is not legal. Hence, Ti is not legal in that scenario. The former 
case is analogous: Tj’s LVis will not contain a write operation from Ti, because Ti follows 
Tj. Therefore T^-’s LVis contains a read on x that returns 1, which is not preceded by any 
write on x, which causes the sequence not to conform to the sequential specihcation and 
renders the transaction not legal. Since either case contains a transaction that is not legal, 
then that history is not final-state last-use opaque, and therefore not last-use opaque. 


27 










4.3 Guarantees 

Last-use opacity gives the programmer the following guarantees: 

Serializability If a transaction commits, then the value it reads can be explained by oper¬ 
ations executed by preceding or concurrent transactions. This guarantees that a transaction 
that views inconsistent state will not commit. 

Lemma 1. Every last-use-opaque history is serializable. 

We provide the proof for Lemma [TOl 

Real-time Order Successive transactions will not be rearranged to fit serializability, so 
a correct history will agree with an external clock, or an external order of events. 

Lemma 2. Every last-use-opaque history preserves real-time order. 

Proof. Trivially from Def. and Def. [21^ . □ 

Recoverability If one transaction reads from another transaction, the former will commit 
only after the latter commits. This guarantees that transactions commit in order. 

Lemma 3. Every last-use-opaque history is recoverable. 

We provide the proof in Appendix [B| 

Precluding Overwriting If transaction Ti reads the value of some variable written by 
transaction Tj, then Tj will never subsequently modify that variable. 

Lemma 4. Last-use opacity does not support overwriting. 

Proof. For the sake of contradiction let us assume that there exists H that is a last-use- 
opaque history with overwriting, i.e. (from Def. there are transaction and Tj s.t.: 

a) Ti releases some variable x early, 

b) H\Ti contains Wi{x)v —> oki and Wi{x)v' oki, s.t. the former precedes the latter in 

Hm, 

c) T{\Tj contains rj{x) —> v that precedes Wi{x)v' — > oki in H. 

Since H is opaque, then there is a completion C = Compl{H) and a sequential history S s.t. 
S = H, S preserves the real-time order of H, and both Ti and Tj in S are legal in S. In S, 
either Ti <s Tj or Tj <s Ti. In either case, any Vis{S, Tj) or LVis{S, Tj) by their definitions 
will contain either the sequence of both Wi{x)v —> oki and Wi{x)v' —> oki or neither of those 
write operation executions. In either case, rj{x) v will not be directly preceded by 
Wi{x)v oki among operations on x in either Vis{S,Tj) or LVis{S,Tj). Therefore, Tj in 
S cannot be legal in S', which is a contradiction. □ 
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1 II invariant: x > 0 

2 transaction { 

3 X = y - 1; 

4 if (x < 0) 

5 abort 0 ; 

6 } 

Figure 19: Abort example. 


1 // invariant: x^O 

2 transaction { 

3 *(_array + x) ; 

4 } 


Figure 20: Memory error example. 


T, 


starti 
o- 


n{yY) 


T, 


Wi(x)-1 ri(ai)-l tryA^ 
---o—-o 

startj . rj{x) -1 

o-^ 


Ai 


Figure 21: Last-use opaque history with inconsistent view. 


Aborting Early Release A transaction can release some variable early and subsequently 
abort. 


Lemma 5. Last-use opacity supports aborting early release. 


Proof. Let H be the history depicted in Fig. 11 Here, Ti releases x early to Tj and sub¬ 


sequently aborts, which satisfies Del. Since and Tj are both aborted in iL, H has a 
completion C = Compl{H) = H. Let S' be a sequential history s.t. S = H\Ti ■ H\Tj. S 
vacuously preserves the real-time order of H and trivially S = H. Transaction Ti in S is 

O 

last-use legal in S, because LVis{S, Ti) = H\Ti whose operations on x are limited to a single 
write operation execution is within the sequential specification of x. Transaction Tj in S 

o o 

is also last-use legal in S, since LVis{S,Tj) = H\Ti ■ H\Tj whose operations on x consist of 
Wi{x)v —> oki followed by rj{x) ^ is also within the sequential specification of x. Since 
both Ti and Tj in S are last-use legal in S, H is final-state last-use opaque. All prefixes 
of H are trivially also final-state last-use opaque (since either their completion is the same 
as iL’s, they contain only a single write operation execution on x, or contain no operation 
executions on variables), so H is last-use opaque. □ 


Exclusive Access Any transaction has effectively exclusive access to any variable it ac¬ 
cesses, at minimum, from the first to the final modification it performs, regardless of whether 
it eventually commits or aborts. 

Lemma 6. Any transaction in any last-use-opaque history has exclusive access to any 
variable between first and last access to. 

Proof. From Lemma and Lemma □ 

However, last-use opacity does not preclude transactions from aborting after releasing 
a variable early. As a consequence there may be instances of cascading aborts, which have 
varying implications on consistency depending on whether the TM model allows transactions 
to abort programmatically. We distinguish three cases of models and discuss them below. 
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Only Forced Aborts Let us assume that transactions cannot arbitrarily abort, but only 
do so as a result of receiving an abort response to invoking a read or write operation, or 
while attempting to commit. In other words, there is no tryA operation in the transactional 
API. In that case, since overwriting is not allowed, the transaction never reveals intermediate 
values of variables to other transactions. This means, that if a transaction released a variable 
early, then the programmer did not intend to change the value of that variable. So, if the 
transaction eventually committed, the value of the variable would have been the same. So, 
if the transaction is eventually forced to abort rather than committing, the value of any 
variable released early would be the same regardless of whether the transaction committed 
or aborted. Therefore, we can consider the inconsistent state to be safe. In other words, if 
the variable caused an error to occur, the error would be caused regardless of whether the 
transaction finally aborts or commits. Thus, we can say that with this set of assumptions, 
the programmer is guaranteed that none of the inconsistent views will cause unexpected 
behavior, even if cascading aborts are possible. Note that the use of this model is not 
uncommon (see eg. [131 [21 [3]). 

Programmer-initiated Aborts Alternatively, let us assume that transactions can arbi¬ 
trarily abort (in addition to forced aborts as described above) by executing the operation 
tryA as a result of some instruction in the program. In that case it is possible to imagine 
programs that use the abort instruction to cancel transaction due to the ’’business logic” 
of the program. Therefore a programmer explicitly specifies that the value of a variable is 
different depending on whether the transaction finally commits or not. An example of such 
a program is given in Fig. |19[ Here, the programmer enforced an invariant that the value 
of X should never be less than zero. If the invariant is not fulfilled, the transaction aborts. 
However, writing a value to x that breaks the invariant is the closing write operation execu¬ 
tion for this program, so it is possible that another transaction reads the value of x before 
the transaction aborts. If the transaction that reads x is like the one in Fig. where x is 
used to index an array via pointer arithmetic, a memory error is possible. Nevertheless, the 
history from Fig. |21| that corresponds to a problematic execution of these two transactions 
is clearly allowed by last-use opacity (assuming that the domain of x is Z). Thus, if the 
abort operation is available to the programmer the guarantee that inconsistent views will 
not lead to unexpected effects is lost. Therefore it is up to the programmer to use aborts 
wisely or to prevent inconsistent views from causing problems, by prechecking invariants at 
the outset of a transaction, or maintaining invariants also within a transaction (in a similar 
way as with monitor invariants). Alternatively, a mechanism can be built into the TM that 
prevents specific transactions at risk from reading variables that were released early, while 
other transactions are allowed to do so. However, if these workarounds are not satisfactory, 
we present a stronger variant of last-use opacity in Section |4.5| that deals specifically with 
this model and eliminates its inconsistent views. 

Arbitrary Aborts We present a third alternative to aborts in transactions: a compromise 
between only forced aborts and programmer-initiated aborts. This option assumes that the 
tryA operation is not available to the programmer, so it cannot be used to implement 
business logic. However, we allow the TM system to somehow inject tryA operations in 
the code in response to external stimuli, such as crashes or exceptions and use aborts as a 
fault tolerance mechanism. However, since the programmer cannot use the operation, the 
programs must be coded as in the forced aborts case, and therefore the same guarantees are 
given. 
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Figure 22: Last-use opaque histories Hjop in relation to: TMS2 and TMSl histories Iltms 2 , 
Eltmsi, opaque histories Hop, elastic opaque histories Heop, rigorous histories H^ig, strict his¬ 
tories Hstr, live opaque histories H/„op, virtual world consistent histories H„ujc, recoverable 
histories H^-ec, histories avoiding cascading abort Hocaj and serializable histories Hger- 

4.4 Last-use Opacity in Context 

We compare last-use opacity with other safety properties with respect to their relative 
strength. Given two properties ‘Pi and *^2 and the set of all histories that satisfy each 
property Hi, H 2 , respectively. tPi is stronger than ^2 if Hi c H 2 (so ^2 is weaker than 
‘Pi). If neither Hi cz H 2 nor Hi 3 H 2 , then the properties are incomparable. 

We present the result of the comparison in Fig. We describe the comparison with 
opacity and serializability in particular below, and provide proofs for the comparison of the 
remaining properties in the appendix. 

Opacity is strictly stronger than last-use opacity. 

Lemma 7. For any history S and transaction Ti e S, if Vis{S,Ti) is legal, then LVis{S,Ti) 
is legal. 

sketch. By definition of Vis{S,Ti), if operation op e Vis{S,Ti), then op e Vis{S,Ti) only if 
op e H\Tj and either i = j or Tj <5 Ti and Tj is committed. By definition of LVis{S,Ti), 
given transactions Ti,Tj and operation op e S\Tj, li i = j or Tj <s Ti and Tj is com¬ 
mitted, then S\Tj c LVis{S,Ti). Therefore LVis{S,Ti) = Vis{S,Ti). Since Vis{S,Ti) and 
LVis{S,Ti) preserve the order of operations in S, then LVis{S,Ti) = Vis{S,Ti). Hence, if 
Vis{S,Ti) is legal, then LVis{S,Ti) is legal. □ 

Lemma 8. Any final-state last-use opaque history H is final-state last-use-opaque. 

sketch. From Def. for any hnal-state opaque history H, there is a sequential history 
S = Compl(H) s.t. S preserves the real time order of H and every transaction Ti in S 
is legal in S. Thus, for every transaction Ti in S Vis{S,Ti) is legal. From the definition 
of completion, any Ti is either committed or aborted in Compl(H) and therefore likewise 
completed or aborted in S. If Ti is committed in S, then it is legal in S, so Vis{S,Ti) is 
legal, and therefore Ti is last-use legal in S. If Ti is aborted in S, then it is legal in S, so 
Vis{S,Ti) is legal, and therefore, from Lemma LVis{S,Ti) is also legal, so Ti is last-use 
legal in S. Given that all transactions in S are last-use legal in S, then, from Def. H is 
final-state last-use opaque. □ 

Lemma 9. Any opaque history H is last-use-opaque. 

Proof. If H is opaque, then, from Def. any prefix P of iL is final-state opaque. Since any 
prefix P of is final-state opaque, then, from Lemma any P is also final-state last-use 
opaque. Then, by Def. is last-use opaque. □ 
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Last-use opacity is strictly stronger than serializability. 
Lemma 10. Any last-use-opaque history H is serializable. 


Proof. For the sake of contradiction let us assume that H is last-use-opaque and not serial¬ 
izable. Since H is last-use-opaque, then from Def. H is also final-state last-use opaque. 
Then, from Def. 21 there exists a completion He = Compl{H) such that there is a sequen¬ 
tial history S' s.t. S = Hq, S preserves the real-time order of He, and any committed 
transaction in S is legal in S. However, since H is not serializable, then from Def. there 
does not exist a completion He = Compl{H) such that there is a sequential history S s.t. 
S = He, and any committed transaction in S is legal in S. This contradicts the previous 
statement. □ 


4.5 Last-use Opacity Variant for the Programmer Initiated Abort 
Model 

Even though last-use opacity prevents inconsistent views in the only forced aborts and 
arbitrary aborts models, it does not prevent inconsistent views in the programmer initiated 
aborts model. Hence, we present a variant of last-use opacity called /3-last-use opacity (/31u 
opacity) that extends the definition of a closing write operation to take tryA operations into 
account, as if it was an operation that modifies a given variable. 

Definition 23 (/3-Closing Write Invocation). Given a program P, a set of processes H 
executing P and a history H s.t. H ^ £(P,H), i.e. H e an invocation inv^{w{x)v) is 

the closing write invocation on some variable x by transaction Ti in H, if for any history 
H' e for which H is a prefix (i.e., H' = H■ R) there is no operation invocation inv' s.t. 
inVj^{w{x)v) precedes inv' in H'\Ti where (a) inv' = inv^{w{x)u) or (b) inv' = inv^{tryA). 

The remainder of the dehnitions of ,31u opacity are formed by analogy to their counter¬ 
parts in last-use opacity. We only summarize them here and give their full versions in the 
appendix. 

The definition of a /3-closing write operation execution is analogous to that of closing 
write operation execution Def. The /3-closing write is used instead of the closing write 
to define a transaction jd-decided on x in analogy to Def. |20| Then, that definition is used to 
define T^, H^Tj, and H\^Tj by analogy to T^, H]Tj and H\Tj. Next, those definitions are 
used to define (dLVis by analogy to LVis. Finally, we say a transaction is jd-last-use legal 
in some sequential history S if f3LVis{S,Ti) is legal. This allows us to define /31u opacity as 
follows. 

Definition 24 (Final-state /3-Last-use Opacity). A finite history H is final-state /3-last-use 
opaque if, and only if, there exists a sequential history S equivalent to any completion of H 
s.t., 

a) S preserves the real-time order of H, 

b) every transaction in S that is committed in S is legal in S, 

c) every transaction in S that is not committed in S is j3-last-use legal in S. 

Definition 25 (/3-Last-use Opacity). A history H is /3-last-use opaque if, and only if, 
every finite prefix of H is final-state /3-last-use opaque. 
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In this variant of last use opacity a transaction is not allowed to release a variable early 
if it is possible that the transaction may execute a voluntary abort. In effect, /31u opacity 
precludes inconsistent views in the programmer initiated abort model. 

The /31u opacity property is trivially equivalent to last-use opacity in the only forced 
abort model (because there are no try A operations in that model), but it is stronger than 
last-use opacity in the arbitrary abort model to the point of being overstrict. 

The /31u opacity property is strictly stronger than last-use opacity in the arbitrary abort 
model, but it is too strong to be applicable to systems with early release. In the first place, 
even though the histories that are excluded by /31u opacity contain inconsistent views, these 
are harmless, because as we argue in Section [4.3[ transactions always release variables with 
“final” values. These final values cannot be reverted by a programmer-initiated abort, so 
if the programmer sets up a closing write to a variable in a transaction, the value that was 
written was expected to both remain unchanged and be committed. Hence, it is accept¬ 
able for these values to be read by other transactions, even before the original transaction 
commits. 

Secondly, the arbitrary abort model specifies that the TM system can inject a tryA 
operation into the transactional code to respond to some outside stimuli, such as crashes. 
Such events are unpredictable, so it may be possible for any transaction to abort at any 
time. Hence, it is necessary to assume that a tryA operation can be produced as the next 
operation invocation in any transaction at any time. In effect, as the definition of /31u opacity 
does not allow a transaction to release a variable early if a tryA is possible in the future, 
/31u opacity actually prevents early release altogether in the arbitrary abort model. 

In summary, /31u opacity is a useful variant of last-use opacity to exclude inconsistent 
views in the programmer initiated abort model (if workarounds suggested in Section 4.3 are 


insufficient solutions). However /31u opacity is too strict for TMs operating in the arbitrary 
abort model, where it prevents early release altogether. For that reason, last-use opacity 
remains our focus. 


5 Supremum Versioning Algorithm 

In this section we discuss the Supremum Versioning Algorithm (SVA), a pessimistic con¬ 
currency control algorithm with early release and rollback support, and demonstrate that 
it satisfies last-use opacity. SVA in its current form was introduced in [Ml EH, although the 
presentation here gives a more complete description. It builds on our rollback-free variant in 
[40l [Ml [39] as well as an earlier version in [30]. Even though the current implementation of 
SVA as part of Atomic RMI is distributed, the concurrency control algorithm itself was cre¬ 
ated for multiprocessor TMs and is applicable to both distributed as well as multiprocessor 
systems. 

The main aspect of SVA is the ability to release variables early. The early release 
mechanism in SVA is based on a priori knowledge about the maximum number of accesses 
that a transaction can perform on particular variables. We explored various methods of 
obtaining satisfactory upper bounds, including static analysis [55] and static typing [Mj- A 
transaction that knows it performed exactly as many operations on some variable as the 
upper bound allows may then release that variable. SVA does not require the upper bounds 
to be precise, and can handle situation when they are either too great (some variables are 
not released early) or too low (transactions are aborted). Since SVA does not distinguish 
between reads and writes when releasing, but instead treats all accesses uniformly, we will 
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34 procedure commit (Transaction Ti) { 

35 for (x : ASetiTi) in parallel) ■[ 

36 wait until pv-(x) - 1 = ltv(a;) 

37 dismiss (Ti, x) 

38 } 

39 if Ox in ASet(Ti) such that rvi(x) > cv(x)) 

40 abort (Ti) and exit 

41 for (x : ASet(Ti) in parallel) {. 

42 delete sti(x) 

43 Itv(x) <— pv.(x) 

44 ]■ 

■[ 45 } 


1 procedure start (Transaction TA {. 

2 for (x : ASet(Ti) sorted by <ik) 

3 lock lk(x) 

4 for (x : ASet{Ti) in parallel) { 

5 gv(x) ^ gv(x) + 1 

6 pVi(x) ^ gv(x) 

7 ]■ 

8 for (x : ASetiTi) sorted by <ik) 

9 unlock lk(x) 

10 > 

12 procedure access(Transaction T , Var x) 

13 wait until pVj(x) - 1 = lv(x) 

14 checkpoint (T , x) 

15 if (rvi(x) A cv(x)) 

16 abort (T, ) and exit 

17 execute read or write 

18 aci(x) <— aci(x) + 1 

19 if (aci(x) = supr^(x)) { 

20 cv(x) <— pv^(x) 

21 lv(x) ^ pv.(x) 

22 } 

23 } 

25 procedure abort (Transaction T) 

26 for (x : ASetiTi) in parallel) ■[ 

27 wait until pv^(x) - 1 = Itv(x) 

28 dismiss (Ti, x) 

29 restore (Ti, x) 

30 delete sti(x) 

31 Itv(x) <— pVj(x) 

32 } 

33 } 


47 procedure checkpoint(Transaction Ti , Var x) { 

48 if (aci(x) = 0) { 

49 copy X to sti(x) 

50 rvi(x) <— cv(x) 

51 y 

52 } 

54 procedure dismiss(Transaction T , Var x) { 

55 if (aci(x) = 0 and rvi(x) = cv(x)) 

56 cv(x) <— pv^(x) 

57 if (pv.(x) - 1 = lv(x)) 

58 lv(x) ^ pv.(x) 

59 } 

61 procedure restore(Transaction T , Var x) { 

62 if (aci(x) A 0 and rvi(x) < cv(x)) { 

63 revert x from sti(x) 

64 cv(x) <— rvi(x) 

65 }■ 

66 }■ 


Figure 23: SVA pseudocode. 


extend the definition of closing write and closing read operation executions to a closing 
access execution which is such a read or write operation, that is not followed by any other 
closing read or closing write operation. 

5.1 Counters 

The basic premise of versioning algorithms is that counters are associated with transactions 
and used to allow or deny access by these transactions to shared objects (rather than only for 
recovery). SVA uses several version counters. The private version counter pVj(x) uniquely 
defines the version of transaction Tj with respect to variable x. The global version counter 
gv(x) shows how many transactions that have x in their access set have started. The local 
version counter lv(x) shows which transaction can currently and exclusively access variable 
X. Specifically, the transaction that can access x is such Ti whose pVj(x) is one greater than 
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lv(a;) (we refer to this as the access condition). The local terminal version counter ltv(a:) 
shows which of the transactions that have x in their access set can currently commit or 
abort. That is, Ti such that x e ASet{Ti) can commit or abort if its pVj(a;) is one greater 
than ltv(a;). 

In addition, the current version counter cv{x) defines what state the variable is in and 
transactions that operate on x will increment its cv(x) to indicate a change of state. It 
will also revert the counter to indicate a rollback (abort). A recovery version counter 
rvi(x) indicates what state variable x was in prior to transaction T^’s modifications. These 
counters are used together to detect whether a variable accessed by the current transaction 
was rolled back by some other transaction, requiring that the current transaction roll back 
as well. These counters also determine which transaction is responsible for reverting the 
state of the variable and to what state it should be reverted. In order be able to revert 
the state of variable SVA also uses a variable store st, where transactions store copies of 
variables before modifying them. 

In order to detect the closing use of a variable, SVA requires that suprema on accesses 
be given for each variable used by a transaction. These are given for each variable x in 
transaction T^’s access set as suprj(a::). If the supremum is unknown suprj(a:) = oo. We 
assume that if a supremum on accessing some variable x is zero, then x is excluded from the 
transaction’s access set. Then, access counter aci(o5j) is used to track the actual number 
of accesses by Ti on x and to check when the supremum is reached, to release a variable 
early. 

Finally, SVA uses a map of locks Ik, containing one lock for each variable to make 
a globally consistent snapshots. Locks are acquired and released in order <iit to prevent 
deadlocks. Initially, all locks are unlocked, counters are set to zero, and the variable store 
is empty. 

5.2 Transactions 

The pseudocode for SVA is shown in Fig. The life cycle of every SVA transaction begins 
with procedure start (we also refer to this part as initialization). Following that, a trans¬ 
action may execute one or more accesses (reads or writes) to shared variables (procedure 
access). After any access or right after start a transaction may then either proceed to 
commit or abort, both of which end a transaction’s life cycle. SVA transactions are pre¬ 
vented from committing until all preceding transactions which released their variables early 
and with which the current transaction shares variables also commit. Accesses to shared 
variables can be interleaved with various transaction-local operations, including accesses to 
non-shared structures or variables. However, those are only visible to the transaction to 
which they are local, so they do not influence other transactions. For the purpose of clarity, 
but without loss of generality, we omit those operations here. We also assume that transac¬ 
tions are executed in a single, fresh, dedicated thread. We also omit the concepts of nested 
and recurrent transactions. 

Start The initialization of a transaction is shown in start at line[^ When transaction Ti 
starts it uses gv(a;) to assign itself a unique version pv^{x) for each variable x in its access set 
ASet{Ti). This must be done atomically and in isolation, so these operations are guarded 
by locks—one lock lk(a;) for each variable used. 
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Accesses Variables are accessed via procedure access at line Before accessing a 
variable, transaction Ti waits for the access condition to be satisfied at line 13 (e.g. for 


the preceding transaction to release it). When this happens, Ti makes a backup copy using 
checkpoint (line|4^. This procedure checks whether this is the first access, and if so makes 
a backup copy of x to sti(a;) at line and sets the recovery counter to the current version 
of X at line [50] to indicate which version of x the transaction first viewed and can revert to 
in case of rollback (abort). Then, the access (either a write or read) is actually performed. 

Afterward, transaction Ti increments the access counter a.Ci{x) (line 18) and proceeds 
to check whether this was the closing access on x by comparing aci(x) to the appropriate 
supremum suprj(a;) (line 19). If this is the case, the variable is released early—i.e, lv(a:) 
is set to the same value as the transaction’s private counter pVj(a;) (line |21[ ). At this point, 
some other transaction Tj, whose pv^ (a:) — 1 = lv(a;) can start accessing the variable using 
procedure access. Another provision made in SVA is that when variable x is released by 
transaction Ti, cv{x) is set to the transaction’s pVj(a;) version (during early release at line 
20). This signifies both that there is a new consistent version of x and that Ti modified x 
the most recently. 


Commit Transaction Ti can attempt to commit using procedure commit at line |34| The 
variables in the transaction’s access set are committed independently (possibly in parallel). 
First, transaction Ti must pass the commit condition at linej^for each variable in its access 
set, so that a transaction is not allowed to commit before all the transactions that accessed 
the same variables as Ti before Ti commit or abort. The transaction then checks whether 
it has access to the variable and if this is not the case, i.e., the variable was not accessed 
at all, waits until the preceding transaction releases it at line |43| Then, the committing 
transaction executes procedure dismiss at line 54 At this point, if the transaction did 


not access the variable before commit, the current version counter is updated (line 56). 


Furthermore, if this transaction has not previously released some variable x, lv(a;) is set to 


pv-(a;) to indicate the object is released (line 58). Finally, the transaction erases backup 
copies from the store st (line [4^ and sets ltv(a;) to its private version counter’s value (line 
43) to indicate that a subsequent transaction can now perform commit or abort on x. 


Abort Aborts are not performed by SVA as part of its basic modus operandi, but aborts 
can be triggered manually by the programmer. Furthermore, such manually-triggered aborts 
can also cause other transactions to abort. If the programmer decides to abort a transaction, 
or if an abort is forced, procedure abort (line |25| ) is used. As with commit, in on order for 
the abort to proceed, the transaction must pass the commit condition at line for each 
variable in its access set. Then, previously unreleased variables are released using dismiss 
(as described above). Afterward, the transaction restores its variables using procedure 
restore (line |61| ). There, if Ti accessed x at least once and the version of x that it stored 
prior to accessing x (rvi(a;)) is lower than the current version of x (cv(x)), then Ti is 
responsible for reverting x to the previous state (condition at line 62). In that case, this 
procedure reverts x to a copy from sti(x) (line [63]). It also sets the current version to rvi(x) 
(line [64|, indicating that variable x was restored to the state just from before Ti modihed 
it. Note that this means that cv(x) was set to a lower value than before. Finally, the 
transaction cleans up sti(x) (line jSOj ) and sets Itv(x) to its private version counter’s value 
(line 1^ . As with commit, this procedure may operate on each variable in parallel. 

If a manual abort is triggered by the user it may be the case that transaction Ti releases 
variable x and aborts after some other transaction Tj already reads the value written to x 
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Figure 24: SVA early release example. The symbol -a—^ denotes an operation execution 
split into the invocation event and the response event to indicate waiting and ' ^ indicates 
what caused the wait. 


by Ti. In that case Tj must be forced to abort along with Ti. Hence, if subsequently the 
situation arises that some other transaction Tj tries to access x after Ti released it early 
and aborted, there is a condition at line [l^ in procedure access which will compare the 
values of cv{x) and TVi{x) for x. If cv(a;) and rvj(x) are equal, that implies Tj currently 
has access to a consistent state of x and can access it. However, if TVj{x) is greater than 
cv(a:), this means that some previous transaction (i.e., Ti) set cv(x) to a lower value than 
it was before, which means it aborted and reverted x. This causes Tj to be forced to abort 
(line |16[ ) instead of accessing x. As an aside, if cv(a:) is greater than rvj{x), then Tj already 
stopped modifying x and released it, so there should not be any more accesses to x. This 
means that Tj violated its upper bound for x and must also be forced to abort. 

Similarly, if transaction Tj tries to commit after Ti aborted, then it checks the condition 
at line |39| for each variable, and if there is at least one variable x for which rvj(x) is greater 


than cv(a;), then again some previous Ti must have aborted and reverted x and Tj must 
then abort too. Note that aborted transactions revert variables in the order imposed by the 
commit condition in wait (line|27[), which ensures state consistency after rollback. 


5.3 Examples 

To illustrate further, the examples in Fig. [24f|27| show some scenarios of interacting SVA 


transactions. In Fig. 24 transactions Ti and Tj both try to increment variable x. Since Ti 


starts before Tj, it has a lower version for x (e.g., pVj(a:)1) than Tj (e.g., pv^(a;) <— 2). 
So, when accessing x, Ti will pass its access condition for x sooner than Tj. Thus, Tj has 
to wait, while Ti executes its operations on x. After its last operation on x, Ti releases 
it by setting x's local counter to its own version (lv(a;) <— 1). From this moment Ti can 
no longer access x. But since the local counter is now equal to 1, which is one lower than 
Tj's version for a: of 2, Tj can now pass the access condition for x and start executing 


operations. In effect Ti and Tj can execute in parallel in part. Fig. 25 shows a similar 


example of a transaction Ti releasing x early and operating on y while a later transaction Tj 
operates on x in parallel. The scenario differs from the last in that Tj finishes work before 
Ti, however it still waits with committing until Ti commits. Fig. |26| shows another similar 
scenario, except Ti eventually aborts. Then, Tj is also forced to abort (and retry) by SVA. 
Note that if meanwhile Tj released x early and some transaction Ty, accessed it, Ty would 
also be aborted. Thus, a cascading abort including multiple transactions is a possibility. 
Finally, Fig. |27| shows two transactions operating on different variables. Since SVA performs 
synchronization per variable, if the access sets of two transactions do not intersect, they can 
both execute in parallel, without any synchronization. 
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Figure 25: SVA wait on commit example. 
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Figure 26: SVA cascading abort example. 

5.4 Safety of SVA 

We present a proof sketch showing that SVA is last-use opaque. A complete proof is in 
AppendixFirst, we make the following straightforward observations about SVA. 

Observation 1 (Version Order). Given the set T)) of all transactions that access x in H 
there is a total order called a version order on s.t. for any Ti,Tj e Ti <x Tj if 
pv.(a;) < pv^.(a:). 

Observation 2 (Access Order). If Ti <j. Tj and Ti performs operation opi on x, and Tj 
performs operation opj on x, then opi is completed in H before opj. 

Observation 3 (No Bufferring). Since transactions operate on variables rather than buffers, 
any read operation op = ri{x) v in any transaction Ti is preceded in H by some write 
operation Wj{x)v okj in some Tj (possibly i = j). 

Observation 4 (Read from Released). If transaction Ti executes a read operation or a 
write operation op on x in H, then any transaction that previously executed a read or write 
operation on x is either committed, aborted, or decided on x before op. 

Observation 5 (Do not Read Aborted). Assuming unique writes, if transaction Ti executes 
Wi{x)v —> u and aborts in H, then x will be reverted to a previous value. In consequence, 
no other transaction can read v from x. 


starti ^t(ai)0 Wi{x)l tryCi—*Ci 
Ti P''.(^)^l lv(ar) = 0? 

start j rj(y)0 ™i(y)l tryCj ^Cj 

Tj P''i(2/)^i !''(:!/) = 0? 


Figure 27: SVA parallel execution example. 
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Observation 6 (Commit Order). If transaction Ti accesses x in H and eommits or aborts 
in H, any transaction that previously executed a read or write operation on x is either 
eommitted or aborted before Ti eommits or aborts. 

Observation 7 (Forced Abort). If transaction Ti reads x from Tj and Tj subsequently 
aborts, then Ti also aborts. 

Then, the main lemma follows, showing that SVA produces final-state opaque histories. 
For convenience, we assume that the SVA program always writes values to variables that 
are unique and in the domain of the variable. 

Lemma 11. Any SVA history H is final-state last-use opaque. 

sketeh. Let He = Compl{H) be a completion of H if for every Ti e H, if Ti is live or commit- 
pending in H, then Ti is aborted in He- Given He we can construct Sh, a sequential history 
s.t. Sh = He, where for any two transactions Ti,Tj e He' 

a) if Ti <Hc Tj, then Ti Tj, 

b) if Ti <x Tj for any variable x, then Ti Tj. 

Note that if some transaction Ti commits in H, then it commits in Sh (and vice versa). 
Otherwise Ti aborts in Sh- 

Let Ti be any transaction committed in H. Thus, Ti also commits in Sh- From Ob¬ 
servation!^ any read operation execution opi = ri{x) —>■ v in H\Ti is preceded in H by 
opj = Wj{x)v —> okj. If opi is local, then i = j, so opj is in a committed transaction. If 
opi is not local, then i j. In that case, from Observation]^ Tj cannot be aborted before 
opi in H. Consequently, Tj is either committed before opi in H, live in H, or committed or 
aborted after opi. In the former case Ti reads from a committed transaction. In the latter 
case, since Ti is committed, then from Observation and Observation we know that Tj 
commits or aborts in H before Ti commits. In addition, from Observation we know that 
Tj cannot abort in H, because it would have caused Ti to also abort. Thus, any committed 
Ti reads only from committed transactions. 

From Observation if Ti reads from the value written by an operation in Tj then the 
write in Tj completes before the read in Ti, which implies Tj <x Ti. Hence, Tj Ti. 
Thus, if Ti is committed in Sh and reads from some Tj, then any such Tj is committed and 
precedes Ti, so SnlTj c Vis{SH,Ti). Since all reads in committed transactions read from 
preceding committed transactions, then for each read in Vis{SH,Ti) reading v from x there 
will be a write operation execution writing t; to a; in Vis{SH, Ti). Since, from Observation]^ 
all accesses on x operations follow < 3 ,, then Vis{SH, Ti) is legal for any committed Ti. Thus, 
any Ti that is committed in Sh is legal in Sh. 

Let Ti be a transaction that is live or aborts in H, so it aborts in Sh. From Observation]^ 
any read operation execution opi = ri{x) v in H\Ti is preceded in H by opj = Wj{x)v 
okj. If opi is local, then i = j, so opj is always in Vis{SH,Ti) where op^ precedes opj. If 
opi is not local, then i ^ j. In that case, from Observation]^ Tj cannot be aborted before 
opi in H. Consequently, Tj is either committed before op^ in H, live in H, or committed or 
aborted after opi. In the former case Ti reads from a committed transaction. In the latter 
case, from Observation ^ we know that either Tj commits in H or Tj is decided on x in H. 
Thus, any committed Ti reads x only from committed transactions or transactions that are 
decided on x. 
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From Observation if Ti reads from the value written by an operation in Tj then the 
write in Tj completes before the read in which implies Tj <x Ti. Hence, Tj Ti. 

Thus, if Ti is aborted in Sh and reads from some Tj, then any such Tj is either committed 
and precedes Ti, so SnlTj c LVis{SH,Ti), or Tj is decided on any x if Ti reads from x, 

^ O 

SO SH\Tj c LVis{SH,Ti). Since all reads in aborted transactions read x from preceding 
committed transactions or transactions decided on x, then for each read in LVis{SH,Ti) 
reading v from x there will be a write operation execution writing v to x. Since, from 
Observation all accesses on x operations follow <x, then LVis{SH,Ti) is legal for any 
aborted Ti. Thus, any Ti that is aborted in Sh is last-use legal in Sh- 

Since any committed Ti in Sh is legal in Sh, and any aborted Ti in Sh is last-use legal 
in Sh, and since Sh trivially follows the real time order of H, then from Def. 21 i? is 
final-state last-use opaque. □ 


Theorem 16. Any SVA history H is last-use opaque. 

Proof. Since by Lemma [XT] any SVA history H is final-state last-use opaque, and any prefix 
P of H is also an SVA history, then every prefix of H is also final-state last-use opaque. 
Thus, by Def. Tf is last-use opaque. □ 


6 Related Work 

Ever since opacity [Hlli] was introduced, it seems, there were attempts to weaken its strin¬ 
gent requirements, while retaining some guarantees over what serializability png provides. 
We explore the most pertinent examples in Section]^ TMSl, TMS2 [TT], elastic opacity iia, 
live opacity [12], and VWC [21], as well as some apposite consistency criteria: recoverability 
[l6] . ACA [7], strictness |7], and rigorousness |9|. Other attempts were more specialized 
and include virtual time opacity m, where the real-time order condition is relaxed. Simi¬ 
larly, the o opacity family of properties |22j relax the time ordering requirements of opacity 
to provide properties applicable to deffered update replication. Another example is view 
transactions [1], where it is only required that a transaction commits on any snapshot, that 
can be different than the one the transaction viewed initially, provided that operating on 
either snapshot produced externally indistinguishable results. While these properties have 
specific applications, none weaken the consistency to allow variable access before commit. 

Although algorithms and systems are not the focus of this paper, some systems research 
that explores relaxed consistency should be noted. We already mention our own SVA m 
in Section]^ Dynamic STM [19] is another system with early release, and it can be credited 
with introducing the concept of early release in the TM context. Dynamic STM allows 
transactions that only perform read operations on particular variables to (manually) release 
them for use by other transactions. However, it left the assurance of safety to the program¬ 
mer, and, as the authors state, even linearizability cannot be guaranteed by the system. The 
authors of [35] expanded on the work above and evaluated the concept of early release with 
respect to read-only variables on several concurrent data structures. The results showed 
that this form of early release does not provide a significant advantage in most cases, al¬ 
though there are scenarios where it would be advantageous if it were automated. We use a 
different approach in SVA, where early release is not limited to read-only variables. Twi¬ 
light STM [8] relaxes isolation to allow transactions to read variables that are used by other 
transactions, and allow them to re-read their values as they change in order to maintain 
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the correctness of the computation. If inconsistencies arise, a reconciliation is attempted on 
commit, and aborts are induced if this is impossible. Since it allows operating on variables 
that were released early, but potentially before closing write, Twilight STM will not satisfy 
the consistency requirements of last-use opacity, but it is likely to guarantee serializability 
and recoverability. 

DATM is yet another noteworthy system with an early release mechanism. DATM 
is an optimistic multicore-oriented TM based on TL2 m, augmented with early-release 
support. It allows a transaction Ti to write to a variable that was accessed by some un¬ 
committed transaction Tj, as long as Tj commits before Ti. DATM also allows transaction 
Ti to read a speculative value, one written by Tj and accessed by Ti before Tj commits. 
DATM detects if Tj overwrites the data or aborts, in which case Ti is forced to restart. 
DATM allows all schedules alowed by conflict-serializability. This means that DATM allows 
overwritting, as well as cascading aborts. It also means that it does not satisfy last-use 
opacity. 

7 Conclusions 

This paper explored the space of TM safety properties in terms of whether or not, and to 
what extent, they allow a transaction to release a variable early, or, in other words, for a 
transaction to read a value written by a live transaction. We showed that existing properties 
are either strong, but prevent early release altogether (opacity, TMSl and TMS2), or pose 
impractical restrictions on the ability of transactions to abort (VWC and live opacity). The 
remainder of the properties are not strong enough for TM applications (serializability and 
recoverability) since they allow a large range of inconsistent views, including overwriting. 
Hence, we presented a new TM safety property called last-use opacity that strikes a reason¬ 
able compromise. It allows early release without a requirement for transactions that release 
early not to abort, but one that is nevertheless strong enough to prevent most inconsistent 
views and make others inconsequential. The resulting property may be a useful practical 
criterion for reasoning about TMs with early release support. 

We discussed the histories that are allowed by last-use opacity and examined the guar¬ 
antees the property gives to the programmer. Last-use opacity always allows for potential 
inconsistent views to occur due to cascading aborts. However, no other inconsistent views 
are allowed. The inconsistent views that can occur can be made harmless by taking away 
the programmer’s ability to execute arbitrary aborts by either removing that operation com¬ 
pletely or by removing it from the programmer’s toolkit, but allowing it to be used by the 
TM system, e.g. for fault tolerance. Allowing the programmer to abort a transaction at 
will means that they will need to eliminate dangerous situations (possible division by zero, 
invalid memory accesses, etc.) on a case-by-case basis. Nevertheless, we predict that incon¬ 
sistent views of this sort will be relatively rare in practical TM applications, and typically 
result from using the abort operation to program business logic. Alternatively, a variant 
of last-use opacity called /I-last-use opacity can be used instead, which eliminates the in¬ 
consistent views by preventing early release in transactions where a programmatic abort is 
possible. 

Finally, we discussed SVA, a pessimistic concurrency control TM algorithm with early 
release, which we show satishes last-use opacity. 
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starti Wi{x)l tryC^^Ci 



start j ^rj(x)l tryCj^Cj 



Figure 28: History Hi, last-use opaque. 

A Last-use Opacity History Examples 

By B we denote that sequence H is a substring of B. 

Note the following about Seq{x) for any x,Ti,Tj: 


[ri{x) -> 0] G Seq{x) (1) 

[wi(x)l ^ oki] G Seq{x) (2) 

[wi(x)l ^ Ai] G Seq{x) (3) 

[wi(x)l ^ oki, fj{x) — > 1] G Seq{x) (4) 

[wi(x)l ^ oki, fj{x) Ai] G Seq{x) (5) 

[wi(x)l ^ oki, fj{x) —> 1, Wj{x)2 —> okj] G Seq{x) (6) 

[wi(a;)l ^ oki, fj{x) — > 1, Wj{x)2 Aj] G Seq{x) (7) 

0 G Seq{x) (8) 

[nix) -> 1] ^ Seqix) (9) 

[wi(x)l ^ oki, u)iix)2 oki, nix) —> 1] ^ Seqix) (10) 

[wi(x)l ^ oki, niy) 1, Tjix) 1, Wjiy)l okj] ^ Seqix) (11) 


Lemma 12. Hi is final-state last-use opaque. 
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Proof. 


let Cl = Compl{Hi) = Hi 
let 5i = Ci|T, • Ci\T, 

Si^Ci 

real time order <u^ = 0 

real time order <Si = {Ti <Si Tj] 

@ A @ 

i = i Si\Ti c Vis{Si,Ti) 

T, T, ^ Si\T^ $ Vts{Si,T,) 
@ A @ ^ Vis{Si,T,) = Si\T, 


p0| ) Vis{Si,Ti)\x = [wi{x)l oki\ 

(m A(§^ Vis{Si,Ti) is legal 
(221 Ti in Si is legal in Si 

T, <si T, A res,(a) e Si\T, Si\T, c Vis{Si,Ti) 
3 = 3 Si\Tj c Vis{Si,Ti) 

@ A @ ^ Vis{Si,T,) = Si\T, ■ Si\Tj 

(26l Vis{Si,Tj)\x = [wi(a;)l oki,rj(x) —>■ 1] 


([2^ A Q ^ Vis{Si,Tj) is legal 
(281 Tj in S'! is legal in 

(141 A (17) A (23) A (29) Hi is final-state last-use opaque 


Let Pf be a prefix s.t. Hi = Pf ■ [reSj{Cj)]. 

Lemma 13. P^ is final-state last-use opaque. 

Proof. 

let Cl = Compl{Pl) = Pi ■ [reSjiCj)] 

Hi = cl A Lemma [12] => Pi is final-state last-use opaque 


Let Pi be a prefix s.t. Hi = P^ ■ [tryCj Cj]. 
Lemma 14. P^ is final-state last-use opaque. 


( 12 ) 

(13) 

(14) 

(15) 

(16) 

(17) 

(18) 

(19) 

( 20 ) 
( 21 ) 
( 22 ) 

(23) 

(24) 

(25) 

(26) 

(27) 

(28) 

(29) 

(30) 

□ 


(31) 

(32) 

□ 
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Proof. 


let C 2 = Compl{Pl) = P 2 ■ [tryA^ Aj] 
let = C^\Ti ■ Cl\Tj 
^2 = 

real time order < pi = 0 

real time order <51= {Ti <51 Tj} 

(361 A (37) =^<si^<pi 
i = i^S^\T,c^ VisiSlT,) 

T, <si T, S^2\T, $ VtsiSlT,) 

(!§ A (@ ^ VisiSlT,) = S^2\T^ 

(^1 Vis{Sl,T^)\x = [wi{x)l -* ofci] 
(@ A§^ Vis{S 2 ,Ti) is legal 


(43) 


Ti in S\ is legal in S. 


T, <si Tj A res,{Ci) e Sl\T, Sl\T, c LVis{SlT,) 

J = 3 ^ S\\T, ^ LVisiSlT^) 

(|^ A (@ ^ LVis{S\,Tj) = S\\Ti ■ Sl\Tj 

(47) LVis{S 2 ,Tj)\x = [wi{x)l oki,rj{x) 1] 

(|^ A (|^ ^ LVis{S 2 ,Tj) is legal 
(491 => Tj in si is last-use legal in 

(351 A (38) A (441 A (501 P^ is final-state last-use opaque 


Let P^ be a prefix s.t. Hi = P^ ■ [reSj(Ci), tryCj Cj]. 

Lemma 15. P 3 is final-state last-use opaque. 

Proof. 

let cl = Compl{Pl) = P3 • [res,(Ci), tryCj Q] 

PI = Cg a Lemma [14] P^ is final-state last-use opaque 


Let Pf be a prefix s.t. Hi = Pf ■ [tryCi Ci, tryCj Cj\. 
Lemma 16. Pf is final-state last-use opaque. 


(33) 

(34) 

(35) 

(36) 

(37) 

(38) 

(39) 

(40) 

(41) 

(42) 

(43) 

(44) 

(45) 

(46) 

(47) 

(48) 

(49) 

(50) 

(51) 

□ 


(52) 

(53) 

□ 
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Proof. 


let cl = Compl{Pl) = PI ■ [tryA^ Ai, tryAj 
let 5 ] = Cl\T, ■ Cl\Tj 
Si ^ Cl 

real time order < pi = 0 

real time order <51= {Ti <si Tj} 

(R A ( 1 ^ ^<„iC<pi 


i4,] 


i = I ^ Sl\T, ^ LVts{Sl,T,) 

T, <si T, Sl\T, $ LVisiSlT,) 
@ A @ ^ LVis{Sl,T,) = Sl\T, 


(^1 Vis{Sl,Ti)\x = [wi{x)l oki] 
([^ A ([|) ^ LVis{Sl,Ti) is legal 
( 641 Ti in S'! is last-use legal in S'] 
'Wi{x) \ oki is closing write on x in = 

" s]|r, c li4*s(s],t,) 


Ti is decided on xS] 


^Sl Tj A ([^1 : 
j = 3 ^ Sl\T, ^ LVis{SlT,) 

LVis{Sl,Tj) = S]|T, -SllT, 


(671 A (68) 


(69) LVis{Sl,Tj)\x = [wi(x)l —> oki,rj{x) -> 1] 

(70) A (|^ LVis{Sl,Tj) is legal 

(711 Tj in S] is last-use legal in S] 

(561 A (59) A (651 A (72) P] is final-state last-use opaque 


Let P] be a prefix s.t. Hi = P^ ■ [reSj(l), tryCi —> Q, tryCj Cj]. 

Lemma 17. P] is final-state last-use opaque. 


(54) 

(55) 

(56) 

(57) 

(58) 

(59) 

(60) 
(61) 
(62) 

(63) 

(64) 

(65) 

( 66 ) 

(67) 

( 68 ) 

(69) 

(70) 

(71) 

(72) 

(73) 

□ 
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Proof. 


let Cl = Compl{Pl) = Pi ■ [resf'{,)tryA^ A^] 
let Si = Cl\T, ■ Cl\T, 

Si - Cl 

real time order <pi= 0 

real time order < 51 = {Ti <51 Tj} 

(771 A (78 1 =^<gi^<pi 


i = i^ Sl\T,c^ LVis{Sl,T,) 

T, <si T, Sl\T, $ LVis{Sl,T,) 
(1^ A (P ^ LVis{SlT,) = Sl\T, 


(821 


Vis{Sl,Ti)\x = [wi(a;)l ^ oki] 

([ 8 |) A (U ^ LVis{Sl,Ti) is legal 
(841 => Ti in si is last-use legal in Sl 

oki is closing write on x in Ti Ti is decided on x 

Sim e LVisiSl,T,) 


Wi{x)l 


Ti <51 Tj A (861 

j = j ^ Sl\T, ^ LVisiSlT,) 

LVis{SlT,) = Slm-Sl\T, 

oki, rj{x) 


(871 A (881 


(891 


(911 


LVis{Sl,Tj)\x = [wi{x)l - 
([^ A (U ^ LVis{Sl,Tj) is legal 




Tj in sl is last-use legal in 55 


(76 1 A (791 A (851 A (921 Pi is final-state last-use opaque 


Let Pi be a prefix s.t. Hi = Pi ■ [ri{x) 1, tryCi Ci, tryCj Cj]. 
Lemma 18. Pg is final-state last-use opaque. 


(74) 

(75) 

(76) 

(77) 

(78) 

(79) 

(80) 
(81) 
(82) 

(83) 

(84) 

(85) 

( 86 ) 

(87) 

( 88 ) 

(89) 

(90) 

(91) 

(92) 

(93) 

□ 
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Proof. 


let cl = Compl{Pl) = Pi ■ [tryA.^ 4^, tryA^ -> Aj] 
let Si = elm ■ Cl\T, 

Si - Cl 

real time order < pi = 0 

real time order <sl = {Ti <51 Tj} 

(^1 A (^1 ^><siC<pi 

t = t^Sl\T,^LVis{Sl,T,) 

T, <si T, Sl\T, $ LVis{SlTi) 

( firol A ^ LVis{Sl,Ti) = Sl\T, 

( 102 1 Vis{Sl,Ti)\x = [wi{x)l -* ofci] 

( fl03| LVis{Sl,Ti) is legal 

(1041 => Ti in si is last-use legal in 5'g 

Wi{x)l oki is closing write on x in Ti Ti is decided on x 

T, <si Tj A ^ Sim e LVis{Sl,T,) 

J = J ^ SllTj ^ LVts{Sl,Tm 

_ ■LVis{Sl,T,) = Slm-Slmj 

LVis{Sl,Tj)\x = [M;i(a;)l ^ oki] 


(1071 A (1081 


(1091 


( [IT^ A^^ LVis{Sl,Tj) is legal 
(111 I => Tj in 5'g is last-use legal in S'g 

(96 1 A (991 A (1051 A (112) Pg is final-state last-use opaque 


(94) 

(95) 

(96) 

(97) 

(98) 

(99) 
( 100 ) 
( 101 ) 
( 102 ) 

(103) 

(104) 

(105) 

(106) 

(107) 

(108) 

(109) 

( 110 ) 
( 111 ) 
( 112 ) 
(113) 

□ 


Let Pj be a prefix s.t. Hi = P^ ■ [reSj(ofci), rj{x) 1, tryCi Ci, tryCj Cj]. 
Lemma 19. P^ is final-state last-use opaque. 
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Proof. 


let Cy = Compl{P^) = P 7 • [res^{Ai), tryAj Aj\ 

(114) 

let ■ C^jTj 

(115) 

S^ = 

(116) 

real time order < pi = 0 

(117) 

real time order <51= {R <gi Tj} 

(118) 

(1171 A(118)^<sic<pi 

(119) 

i = i^ S^\Ti c LVis{S^,T,) 

( 120 ) 

T, <si Tj S]\Tj $ LVis{S],R) 

( 121 ) 

(1201 A (121) ^ LVis{S],Ti) = S^\T, 

( 122 ) 

(122) ^ Vis{S],Ti)\x = [w,{x)l ^ 

(123) 

(123) A (|2| ^ LVis{S],Tf) is legal 

(124) 

(124) Ti in S 7 is last-use legal in Sj 

(125) 

Wi(x)l —> Ai is not closing write on x in Ti 

(126) 

Sy Pj a;\{?i;i(a:)l ^ TJ = 0 

(127) 

resJQ) f S]\T, a (127) ^ sf\T, $ LVis{S\,Tj) 

(128) 

3 = j ^ S]\Tj ^ LVis{S],Tj) 

(129) 

(128) A (129) ^ LVisiSj^Tj) = SjP, 

(130) 

(130) ^ LVis{S],Tj)\x = 0 

(131) 

(131) A (| 8 |) LVis{S],Tj) is legal 

(132) 

(132) Tj in S 7 is last-use legal in S] 

(133) 

(116) A (119) A (125) A (133) P 7 is final-state last-use opaque 

(134) 

□ 


Let Pp be a any prefix s.t. Hi = Pp ■ R - ^ oki, rj{x) 1, tryC^ —> Ci, tryCj 

C,]. 

Lemma 20. Any Pp is final-state last-use opaque. 

Proof. Since Pp does not contain any reads or writes, for any sequential history S' = Pp, 
transactions Ti and Tj are trivially both legal and last-use legal in S. Thus, Pp is final-state 
last-use opaque. □ 


Lemma 21. Hi is last-use opaque. 


Proof. Since, from Lemmas 35 - 20 all prefixes of Hi are final-state last-use opaque, then by 
Def. Hi is last-use opaque. □ 


Corollary 8. Any prefix of Hi is last-use opaque. 


Lemma 22. H 2 is final-state last-use opaque. 


52 






























starti 


Wi{x)l 


T,; 




tryCi Ci 


startj ' rj{x)l tryCj^Cj 


T, 


Figure 29: History H 2 , not last-use opaque. 


Proof. 


let C 2 = Compl{H 2 ) = H 2 (135) 

let S'2 = CilT,-CalTj- (136) 

S 2 = C 2 (137) 

S'2 = 5*1 A Lemma [12] H 2 is final-state last-use opaque (138) 


□ 

Let Pf be a prefix s.t. H 2 = Pf ■ [reSj(Ci)]. 

Lemma 23. Pf is final-state last-use opaque. 

Proof. 

let Cf = Compl{Pl) = Pf • [reSjiCj)] (139) 

H 2 = Cl A Lemma [22] P^ is final-state last-use opaque (140) 

□ 

Let Pf be a prefix s.t. H 2 = Pf ■ [tryC^ Ci\. 

Lemma 24. Pf is not final-state last-use opaque. 
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Proof. 


let Cf = Compl^P^) = Pi • [tryAj Aj\ 

(141) 

let Si = Cl\Ti ■ Cl\Tj 

(142) 

q2 _ 

^2 = ^2 

(143) 

real time order <p 2 = 0 

(144) 

real time order <s^= {Ti <sl Tj} 

(145) 

(1441 A (1451 ^<s2^<p2 

(146) 

res.iA,) G Sl\T, Sl\T, $ LVts{SlT,) 

(147) 

J = J ^ Sl\T, ^ LVtsiSlT,) 

(148) 

(1471 A (1481 ^ LVis{Sl,T,) = Sl\T^ 

(149) 

(1491 ^ LVisiSl,Ti)\x = [r,(a:) ^ 1] 

(150) 

(1501 A (|9|) LVis{Sl,Tj) is not legal 

(151) 

(1511 Tj in si is not legal in Sl 

(152) 

let Sl = Cl\Tj ■ Cl\Ti 

(153) 

q2 _ /^2 

^2 = ^2 

(154) 

real time order <p 2 = 0 

(155) 

real time order < 52 = {Ti <^2 Tj} 

(156) 

(1551 A (1561 ^<i,2^<p2 

(157) 

Tj <sl T, Sl\T, $ Vis{SlT^) 

(158) 

3 =3^SI\T^^ Vis{Sl,Ti) 

(159) 

(1581 A (1591 ^ Vis{Sl,Tj) = Sl\Tj 

(160) 

(I 6 OI => Vis{Sl,Tj)\x = [rj{x) 1] 

(161) 

(I 6 II A (|9|) LVis{Sl,Tj) is not legal 

(162) 

(1621 => Tj in sl is not legal in 

(163) 

(1521 A (1631 P| is not final-state last-use opaque 

(164) 

□ 


Lemma 25. H 2 is not last-use opaque. 


Proof. Even though, from Lemma H 2 is final-state last-use opaque, from Lemma “M 
prefix Pf of H 2 is not final-state last-use opaque, so, from Def. 22 H 2 is not last-use opaque. 

□ 


Lemma 26. H 3 is final-state last-use opaque. 
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starti 


Wi{x)l tryA^—*Ai 


T, 

startj , 0 (^) 1 injCj 



Figure 30: History H 3 , last-use opaque. 


Proof. 


let C 3 = Compl{H-i) = H 3 (165) 

let ^3 = CalT,-CalF, (166) 

53 = C3 (167) 

real time order <h 3 = 0 (168) 

real time order < 3 ^= {Ti < 3 ^ Tj} (169) 

( 1^ A ([^ ^<s^^<h 3 (170) 

I = i ^ SslT, LVis{S 3 ,T,) (171) 

r, <S3 T, ^ SslT, $ LVisiSs, Ti) (172) 

{TjA A ^ ^ LVis{S 3 ,T,) = SslT, (173) 

( T^ ^ Vis{S 3 ,T,)\x = K(x)l ok,] (174) 

A (U ^ LFis(S'3,Ti) is legal (175) 

( [Tt^ Ti in S 3 is last-use legal in S 3 (176) 

Wi(x)l oki is closing write on x in Ti Ti is decided on XS 3 (177) 

T, <S3 T, A ^ 53IT, c LVis{S3, T,) (178) 

j = j^ S 3 Tj c LVis{S 3 , T,) (179) 

[17^ A (|^ ^ LVis{S 3 , Tj) = • S 3 \Tj (180) 

(I8OI LVis{S 3 ,Tj)\x = [wi(a;)l —> oki,rj{x) 1] (181) 

( IMI A (|4]) ^ LVisiSs^Tj) is legal (182) 

(1821 Tj in S 3 is last-use legal in S 3 (183) 

(1671 A (170) A (176) A (183) H 3 is final-state last-use opaque (184) 


□ 

Let Pf be a prefix s.t. H 3 = Pf • [reSj{Aj)]. 

Lemma 27. Pf is final-state last-use opaque. 

Proof. 

let Cf = Compl{Pi) = Pi ■ [reSj{Aj)] (185) 

H 3 = Cf A Lemma [Ml => Pf is final-state last-use opaque (186) 

□ 
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Let P 2 be a prefix s.t. H 3 = ■ [tryCj Aj\. 

Lemma 28. P 2 is final-state last-use opaque. 
Proof. 


let C 2 = Compl{P 2 ) = P- 
let Si = Cl\T, ■ Cl\Tj 


[try A, 


c3 _ /^3 

*^2 = ^2 

real time order <p 3 = 0 

real time order <53= {Ti <53 Tj} 

A ^ 

i = i^ Sl\Ti c LVis{Sl,Tf) 

T, <03 T, Sl\T, $ LVis{Sl,Tf) 


( 1^ A ([^ ^ LVis{Sl,Ti) = Sl\T, 
(1951 Vis{Sl,Ti)\x = [wi{x)l —> oki] 
( 19^ A (U ^ LVis{Sl,Tf) is legal 


(1971 Ti in si is last-use legal in Sl 

Wi{x)l oki is closing write on x in Ti => 

T, <S3 T, A (H ^ S(\T, c LVtsiSlTj) 


Ti is decided on xSl 


J = J 


Sl\T, c LVis{SlT,) 


( 200| A ([^ ^ LVis{Sl,Tj) = Sl\Ti ■ Sl\Tj 
(2021 LVis{Sl,Tj)\x = [wi{x)l oki,rj(x) 
( ^ A (|^ ^ LVis{Sl,Tj) is legal 
(mi 


1 ] 


Tj in sl is last-use legal in Sl 


(1891 A (1921 A (1981 A (2051 Pf is final-state last-use opaque 


Let be a prefix s.t. = P^ ■ [tryCj Aj]. 

Lemma 29. P 3 is final-state last-use opaque. 

Proof. 

P^ = PI A Lemma fTHl P3 is final-state last-use opaque 


Let Pp be a any prefix s.t. P3 . 

Lemma 30. Any Pp is final-state last-use opaque. 


(187) 

(188) 

(189) 

(190) 

(191) 

(192) 

(193) 

(194) 

(195) 

(196) 

(197) 

(198) 

(199) 

( 200 ) 
( 201 ) 
( 202 ) 

(203) 

(204) 

(205) 

(206) 

□ 


(207) 

□ 
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starti 


Wi{x)l tryAj^^Ai 


T, 




start j 'rj{x)l tryCj^Cj 


T, 


Figure 31: History H 4 , not last-use opaque. 


Proof. 


Hi = PI ■ R A Corollary^=^ Pi is last-use plague 
PI = P| a (2081 is last-use lopaque 

(2091 P 3 is final-state last-use lopaque 


(208) 

(209) 

( 210 ) 

□ 


Lemma 31. is last-use opaque. 


Proof. Since, from Lemmas 27 -30 all prefixes of H 3 are final-state last-use opaque, then by 
Def. H 3 is last-use opaque. □ 

Corollary 9. Any prefix of H 3 is last-use opaque. 


Lemma 32. H 4 is not final-state last-use opaque. 
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Proof. 


let Ci = Gompl{P[i) = 

( 211 ) 

let S '4 = C 4 IT, • C 4 |r^- 

( 212 ) 

III 

(213) 

real time order <p^= 0 

(214) 

real time order < 84 ,= {Ti < 84 , Tj} 

(215) 

(214) A (215) 

(216) 

res,{A,) G S4m SilT^ $ Vis{S 4 ,Tj) 

(217) 

j = j ^ S 4 \Tj c Vis{S 4 ,Tj) 

(218) 

(217) A (218) ^ Vis{S 4 ,Ti) = S 4 \Tj 

(219) 

(219) ^ Vis{S 4 ,T 4 )\x = [r,(a;) ^ 1] 

( 220 ) 

(220) A (|9| Vis{S 4 ,Tj) is not legal 

( 221 ) 

(221) Tj in 5'4 is not legal in S 4 

( 222 ) 

let ^4 = C 4 \Tj ■ C 4 \Ti 

(223) 

III 

(224) 

real time order <p^ = 0 

(225) 

real time order <g^= {Ti <g^ Tj} 

(226) 

(225) A (226) 

(227) 

Tj <84 S4\T, $ Vis{S4,T,) 

(228) 

j=j^S 4 \Tj<^ Vis{S 4 .Ti) 

(229) 

(228) A (229) ^ Vis{S4,Tj) = S 4 \Tj 

(230) 

(230) ^ Vis{S 4 ,Tj)\x = [rj{x) 1] 

(231) 

(231) A |9|) Vis{S 4 ,Tj) is not legal 

(232) 

(232) Tj in ^4 is not legal in S 4 

(233) 

(222) A (233) P 4 is not final-state last-use opaque 

(234) 

□ 


Lemma 33. is not last-use opaque. 


Proof. From Lemma 32 is not final-state last-use opaque, then so, from Def. 22 is not 
last-use opaque. □ 


Lemma 34. is final-state last-use opaque. 
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starti 


Wi{x)l tryCi^Ci 


start j rj{x)l tryCj^Cj 



Figure 32: History not last-use opaque. Note that write in Ti is not closing write. 


Proof. 


let Cs = Compl{Hf) = 
let 55 = CsiT, • CslT, 


S5^C5 

real time order <h 5 = ^ 

real time order < 3 ^ = {Ti <s^ Tj} 

( 2 ^ A ([2^ 

85 = Si A A ( 1 ^ A (pi A ((2I 


H5 is final-state last-use opaque 


Let Pi be a prefix s.t. = Pf • [reSj{Cj)]. 

Lemma 35. Pf is final-state last-use opaque. 

Proof. 

let Cl = Compl{Pl) = Pi ■ [resyiCj)] 

P5 = cl A Lemma fH => Pf is final-state last-use opaque 


Let Pi be a prefix s.t. = P^ ■ [tryCj Cj]. 
Lemma 36. P| is final-state last-use opaque. 


(235) 

(236) 

(237) 

(238) 

(239) 

(240) 

(241) 

□ 


(242) 

(243) 

□ 
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Proof. 


let Cl = Compl{Pl) = P| • [tryA^ Aj] 
let Si = Cl\T, ■ Cl\Tj 

c5 _ /^5 

*^2 = ^2 

real time order <p|= 0 

real time order <s|= {Ti <55 Tj } 

(2471 A (248) =^<s5^<p5 

i = i^Sl\T,^ Vis{Sl,Tf) 

T. <55 T, Sl\T, $ Vts{SlTf) 


( ^ A ([^ ^ Vis{Sl,Ti) = Sl\T, 

(252) Vis{Sl,Ti)\x = [wi(a;)l oki\ 

( ^ A (U ^ Vis{Sl,Ti) is legal 
(254) Ti in Sl is legal in Sl 

T, <s5 Tj A res,(Q) e Sl\T, Sl\T, c LVis{Sl,T,) 
j = j ^ Sl\T, ^ LVis{Sl,T,) 


( 256| A ([^ ^ LVis{Sl,Tj) = Sl\Ti ■ Sl\Tj 
(258) LVis{SlTTj)\x = [^^(a;)! ^ oki^rj{x) 
(^ A (El ^ LVis{Sl,Tj) is legal 


1 ] 


(2601 Tj in Sl is last-use legal in Sl 

(246) A (249) A (255) a (261) P| is final-state last-use opaque 


Let P3 be a prefix s.t. P5 = P3 • [reSj(Pi), tryC^ Cj\. 

Lemma 37. P 3 is final-state last-use opaque. 

Proof. 

let Cl = Compl{Pi) = P| • [resfiC,), tryC^ ^ Q] 

Pi = cl A Lemma [33 P| is final-state last-use opaque 


Let P4 be a prefix s.t. P5 = Pg^ • [tryCi Ci, tryCj Cj\. 
Lemma 38. Pf is not final-state last-use opaque. 


(244) 

(245) 

(246) 

(247) 

(248) 

(249) 

(250) 

(251) 

(252) 

(253) 

(254) 

(255) 

(256) 

(257) 

(258) 

(259) 

(260) 
(261) 
(262) 

□ 


(263) 

(264) 

□ 
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Proof. 


let C| = Compl{Pl) = Pi ■ [tryA^ - 
let ^1 = Cl\T, ■ Cl\T, 

c5 — 

O 4 = 04 

real time order <p5= 0 

real time order <s|= {Ti <55 Tj} 

(268l A (269l =^<.g5^<.p5 

Wi{x)l 


A, tryA, Aj] 


oki is not closing write on x in Ti 
T, <s5 T, A (H ^ S(\T, $ LVis{SlTj) 


Ti is not decided on x 


j = j ^ Sl\T, ^ LVis{SlT,) 

\272\ A (|273|) ^ LVis{Sl,T,) = ^||r, • Sl\T, 
3 {SI,Tj)\x = [rj{x) 1 ] 

> LVis{Sl,Tj) is not legal 


( |274 l 

( [ 2 ^ A (|4| 
([2761 


Tj in 51 is not last-use legal in 51 
let = Cl\Tj ■ Cl\T, 

q5 — 

O 4 = 04 

real time order <p 5 = 0 

real time order < 55 = {A <^5 Tj} 

(2801 A (2811 


A' A 


Sl\T, $ LVisiS!,T,) 


J =3 ^Sl\T, c LVis{SlT,) 


(|283| A (|284| ^ LVis{Sl,Tj) = Sl\T. 


65 I 


(2851 


LVis{Sl,Tj)\x = \rj{x) 


1 ] 

(2861 A ^ LVis{Sl,Tj) is not legal 
Tj in 5| is not legal in 


(2871 


(2771 A (2881 Pf is not final-state last-use opaque 


(265) 

(266) 

(267) 

(268) 

(269) 

(270) 

(271) 

(272) 

(273) 

(274) 

(275) 

(276) 

(277) 

(278) 

(279) 

(280) 
(281) 
(282) 

(283) 

(284) 

(285) 

(286) 

(287) 

(288) 
(289) 

□ 


Lemma 39. is not last-use opaque. 

Proof. Even though, from Lemma |34[ is final-state last-use opaque, from Lemma |38[ 


prefix Pi of is not final-state last-use opaque, so, from Def. 


22 


is not last-use opaque. 

□ 


Lemma 40. Hq is not final-state last-use opaque. 
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T, 


starti Wi{x)l Wi{x)2 tTyC^^ Ci 
o-o-o-o 

start j ■■ Tj {x) 1 tryAj —* Aj 

o -o-o 



Figure 33: History Hq, not last-use opaque. 


Proof. 


let Cq = Compl{HQ) = Hq 
let ^6 = Ce\T, ■ Ce\T, 

Se^Ce 

real time order <//g= 0 

real time order <Se= {Ti <Se Tj} 

<Se^<He 

Se\T, ^ LVis{Se,T,) 


(2931 A (2941 


Ti <Se Tj A reSj(Q) e Se\T, = 

j = j ^ Se\T, ^ LVis{Se,T,) 


(2961 A (2971 ^ VtsiSe,Tj) = Se\T ,' ^-elT, 


(2981 Vis{Se,Tj)\x = [wi(a;)l 
(2991 A (10) => Vis{Se,Tj) is not legal 


oki, Wi{x)2 


oki, rj(x) 1] 


(300) 


Tj in Sq is not legal in Sq 


let ^6 = CelT, • Cq\T, 

real time order <He = 0 

real time order <5 = <o Tj} 


ST 

<c 


( |304| A ([^ 

Tj <s, T, S^\Tr $ LVis{Se,T^) 
j = j ^ Se\T, LVis{Se,T,) 

( [307I A LVis{Se,Tj) = Se\Tj 

( [30^ ^ LVis{Se,Tj)\x = [rj{x) 1] 
(310) A ^ LVis{Se,Tj) is not legal 


(3111 Tj in Sq is not legal in Sq 


(301) A (312) Hq is not final-state last-use opaque 


(290) 

(291) 

(292) 

(293) 

(294) 

(295) 

(296) 

(297) 

(298) 

(299) 

(300) 

(301) 

(302) 

(303) 

(304) 

(305) 

(306) 

(307) 

(308) 

(309) 

(310) 

(311) 

(312) 

(313) 

□ 


Lemma 41. Hq is not last-use opaque. 


Proof. From Lemma 40 is not final-state last-use opaque, then so, from Def. 22 Hq is not 
last-use opaque. □ 
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starti 


T,, 


T, 


Wi(x)l tryC^^Ci 

-o 

startj rj{x) 1 tryA^ —> Aj 

D-O-O 


Figure 34: History Hy, last-use opaque. 

Lemma 42. Hj is final-state last-use opaque. 

Proof. 

(314) 

(315) 

(316) 

(317) 

(318) 

(319) 

(320) 

(321) 

(322) 

(323) 

(324) 

(325) 

(326) 

(327) 

(328) 

(329) 

(330) 

(331) 

(332) 


□ 

Let Pf be a prefix s.t. iJr = Pf ■ [reSj(Ci)]. 

Lemma 43. Pf is final-state last-use opaque. 

Proof. 

let cl = Compl{Pl) = PI ■ [res^{Ci)\ (333) 

H-j = cl A Lemma l42l P/ is final-state last-use opaque (334) 

□ 


let Cr = Compl{Hj) = H-j 
let 57 = C7|r, • Cr\T, 

S7^C7 

real time order <77^= 0 

real time order <Sr= {Ti <Sy Tj} 

( MtI a ([^ 

i = i^ S7\T, c Vis{S7,Tf) 

T, <s, Tj 57IT, $ Vis{S 7 ,Ti) 
(3^ A Vis{S7,Tf) = S7\T, 


( 32^ ^ Vis{S7,Ti)\x = [wi{x)l ok,] 

(32^ A (U ^ LVis{S 7 ,Ti) is legal 

(3241 => Ti in S 7 is last-use legal in S 7 

T, <s, Tj A res,{C,) e S7\T, S7\T, c Vts{S7,T,) 

j=j^S7 \T,^ Vis{S7 ,T,) 

( 3^ A ([^ ^ Vis{S7,Tj) = S7\Ti ■ S7 \Tj 

(3281 LVis{S 7 ,Tj)\x = [w;i(a;)l ^ oki,rj{x) —> 1] 
(3^ A (11 ^ LVis{S 7 ,Tj) is legal 


(3301 


Tj in S 7 is last-use legal in S 7 


(3161 A (319) A (325) a (331) H 7 is final-state last-use opaque 
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Let Pj be a prefix s.t. Hj = ■ [tryC^ Ci\. 

Proof. 

let cl = Compl{Pl) = Pj • [tryA^ Ai\ 
let Si = Cl\T, ■ Cl\Tj 
Si ^ Cl 

real time order <p^= 0 

real time order <sl= {Ti <sl Tj) 

(3381 A (339) =^<s7^<p7 
i = i^ Sl\Ti c LVis{Sl,T,) 

T, <si Tj Sl\T, $ LVis{Sl,Tf) 

( HT| A (1^ ^ LVis{Sl,Ti) = Sl\T, 

(343) Vis{Sl,Ti)\x = [wi{x)l —>■ oki] 

( ^ A (U ^ LVis{Sl,Tf) is legal 
(3451 Ti in S'J is last-use legal in Sl 

Wi(x)l oki is closing write on x in Ti Ti is decided on x 

T, <si TjA^^ SI]t, c LVis{SlT,) 

3 = J ^ Sl\T, LVis{Sl,T,) 

( 34^ A LVis{Sl,Tj) = sflTi ■ Sl\Tj 

(350) LVis{Sl,Tj)\x = [wi(a:)l —> oki\ 

( ^ A ([^ ^ LVis{Sl,Tj) is legal 
(3521 Tj in Sl is last-use legal in Sl 

(3371 A (340) A (3461 a (3531 Pj is final-state last-use opaque 


Lemma 44. Pj is final-state last-use opaque. 

Proof. 

let cl = CompfiPl) = Pi ■ [reSj{Aj), tryCi P,] 

PI = cl A Lemma |44] Pj is final-state last-use opaque 

Let Pj be a prefix s.t. H 3 = Pj ■ [tryCj Aj, tryCi Ci\. 

Lemma 45. Pj is final-state last-use opaque. 

Proof. 

Pj = P| A Lemma [38] Pj is final-state last-use opaque 


(335) 

(336) 

(337) 

(338) 

(339) 

(340) 

(341) 

(342) 

(343) 

(344) 

(345) 

(346) 

(347) 

(348) 

(349) 

(350) 

(351) 

(352) 

(353) 

(354) 

□ 


(355) 

(356) 

□ 


(357) 

□ 
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start,I 


o- 

T^ 


Wi{x)i nivU 

^- 


start j 





Wj{y)l 

- 


Figure 35: History iJg, not last-use opaque. 


Let Pp be a any prefix of Pj. 

Lemma 46. Any Pj is final-state last-use opaque. 
Proof. 


Hi = P4 • i? A Corollary^^^ PI is last-use lopaque 
PI = pJ a { 3581 Pj is last-use lopaque 


(3591 


PI is final-state last-use lopaque 


(358) 

(359) 

(360) 

□ 


Lemma 47. Hj is last-use opaque. 


Proof. Since, from Lemmas 43 - 46 
Def. Hr is last-use opaque. 


all prefixes of Hr are final-state last-use opaque, then by 

□ 


Lemma 48. 


iLs is not final-state 


last-use opaque. 
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Proof. 


let Cg = Compl{Hg,) = iLg 


(361) 

let ^g = Cg|r, • Cg|r, 


(362) 



(363) 

real time order <Hg= 0 


(364) 

real time order <Ss= {Ti <S8 '^j} 


(365) 

(3641 A (365) ^<s8^<h8 


(366) 

T, <S8 Tj A res,iQ) e 5g|T, ^ ,5g|r, c LVis{Ss,T,) 


(367) 

j = j ^ Ss\T^ ^ LVisiSs,T,) 


(368) 

(367) A (368) ^ Vis{Ss,T,) = Ss\T, ■ Ss\T, 


(369) 

(369) ^ Vis{Ss,Tj)\x = [w;i(a;)l ^ oki,ri{y) l,r,(x) ^ 1 

, Wj{y)l okj] 

(370) 

(370) A (11) Vis{Ss,Tj) is not legal 


(371) 

(371) Tj in Ss is not legal in Ss 


(372) 

let 5g = Cg|r, • Csm 


(373) 

Ss^Cs 


(374) 

real time order <Hg= 0 


(375) 

real time order <g^= {Ti <g^ Tj} 


(376) 

(375) a(376)^<s^c<^^ 


(377) 

Tj <Ss T^ Ss\T, $ LVis{Ss,T,) 


(378) 

j = j ^ Ss\T, LVisiSs,T,) 


(379) 

(378) A (379) ^ LVis{Ss,T^) = 5g|T, 


(380) 

(380) ^ LVis{Ss„Tj)\x = [wj{y)l oki,rj{x) l,n(y) ^ 

1 , Wi{x)l ok^] 

(381) 

(381) A (11) LVis{Ss,Tj) is not legal 


(382) 

(382) Tj in Ss is not legal in 5g 


(383) 

(372) A (383) Hs is not final-state last-use opaque 


(384) 

□ 


Lemma 49. is not last-use opaque. 


Proof. From Lemma 48 is not final-state last-use opaque, then so, from Def. 22 iLg is not 
last-use opaque. □ 


Lemma 50. Hg is final-state last-use opaque. 
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starti 


T, 


Wi{x)l tryAi^Ai 
o-@-o 

startj ' ry(x)l Wj{x)2 

o -o--@- 

Tj 

start k rk{x )0 

o - 0 - 

Tk 


Figure 36: i/g, last-use opaque. 


Proof. 


let Cg = Compl^Hg) = ■ [tryA^ —> Aj, tryAj, Ak\ 

let 5g = CgiT, • Cg|T, • CglTfe 

S9^Cg 

real time order <Hg= {Ti <Hg Tk} 

real time order < 59 = {Ti <Sg Tj,Ti <Sg Tk,Tj <Sg Tk] 

(3881 A (3^1 =^<Sg^<Hg 


i = I ^ SglT, ^ LVis{S9 ,T,) 

T^ <sg Tj SglT, $ LVis{S9.Ti) 

T^ <sg Tk SglTk $ LVis{S9,Ti) 

( [Ml] ) A (|^ A (j^ ^ LVis{SQ,Ti) = SglT, 

(394) LVis{Sg,Ti)\x = \wi{x)l —> oki\ 

( [Ms] A (H ^ LVis{S 9 ,Ti) is legal 
( |M^ => Ti in 5'g is last-use legal in 5'g 

Wi{x)l —> oki is closing write on x in Ti Ti is decided on x in Sg 
Sg]T, C LVis{Sg,Tj) 


T, <Sg Tj A (j^l 

j = j ^ Sg 
Tj <SgTk = 


Tj c LVis{Sg,Tj) 
Sg\Tk $ LVis{Sg,T,) 


(399) A (400) A (401) 


(402) 


LVts{Sg,Tj) = Sg\T,-Sg\T, 
LVis{Sg, Tj)\x = [wi(a:)l —> oki, rj(x) —> 1, Wj(x)2 


okj] 


(414) A (|^ LVis{Sg,Tj) is legal 
(|404|) Tj in Sg is last-use legal in Sg 


(385) 

(386) 

(387) 

(388) 

(389) 

(390) 

(391) 

(392) 

(393) 

(394) 

(395) 

(396) 

(397) 

(398) 

(399) 

(400) 

(401) 

(402) 

(403) 

(404) 

(405) 

(406) 
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T. <Sg n A ^ Sq\T, c LVis{Sg,Tk) or Sg\T, $ LVis{Sg,Tk) 

( M ) ^ Sgh $ LVts{S 9 ,n) 

Wj{x)2 okj is closing write on x in Tj Tj is decided on x in Sg 
Tj <s, Tk A @ ^ c LVtsiSg.Tk) or Sg]Tj $ LVis{Sg,n) 

^ ^ Sg]T, LVtsiSg,Tk) 
k = k ^ Sg\Tk ^ LVis{Sg,Tk) 

M A A ^ LVis{Sg,Tk) = Sg\Tk 
( FT3| ) ^ LVis{Sg,Tk)\x = [rj{x) ^ 0] 
dint A Q ^ LVis{Sg,Tk) is legal 
(415) Tk in Sg is last-use legal in Sg 

(387) A (390) A (397) a (405) a (416) => Hg is final-state last-use opaque 


Let Pf be a prefix s.t. Hg = P® • [resj,(0)]. 
Lemma 51. Pf is final-state last-use opaque. 
Proof. 

let Cl = CompfiPl) = Pf • [tryAj 

let Sf = Cl\T, ■ Cl\T, ■ Cl\Tk 
- 


Aj,reSk{Ak)] 


SI = Cl 

real time order <p9 = {Ti <p9 Tk} 

real time order <^9= {T^ <^9 Tj,Ti <^9 Tk,Tj <59 Tk] 
(421| A (|422t ^><59C<p9 
i = i^ Sl\T,^ LVisiSlT,) 

T, <s9 Tj Sl\Tj $ LVisiSlT,) 

Ti <59 Tk 


(424) A (425) A (426) 


(427) 


Sl\Tk $ LVtsiSlT,) 

LVtsiSl,T,) = Sl\T, 

oki] 


_ LVis{Sl,Ti)\x = [wi{x)l 

( 4^ A (H ^ LVis{Sl,Ti) is legal 
(429) => Ti in Sf is last-use legal in Sf 


(407) 

(408) 

(409) 

(410) 

(411) 

(412) 

(413) 

(414) 

(415) 

(416) 

(417) 

□ 


(418) 

(419) 

(420) 

(421) 

(422) 

(423) 

(424) 

(425) 

(426) 

(427) 

(428) 

(429) 

(430) 

(431) 
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Wi(x}l oki is closing write on x in Ti Ti is decided on x in S\ 
T, <s9 Tj A ^ sf\T, c LVis{Sf,T,) 
j = j ^ S!\T, ^ LVts{S!,T,) 

Tj <s9 Tk Sl\Tk $ LVisiSlT,) 


(|433|) A (|434|) A (|435|) ^ LVis{Sl,Tj) = Sl\T, ■ Sl\Tj 


(436) 


LVis{Sf,Tj)\x = [wi{x)l oki, rj{x) 1, Wj{x)2 okj] 
LVis{Sl,Tj) is legal 


( |447[ ) A ^ iTAA^C-9 
(438) => Tj in Sf is last-use legal in Sf 

T, <s9 Tk A (H ^ sf\T, c LVis{Sf,Tk) or sf\T, $ LVis{Sf,Tk) 


LVis{St,Tk) 

Wj{x)2 okj is closing write on x in Tj Tj is decided on x in Sf 
Tj <s9 Tk A (Q ^ c LVis{Sl,Tk) or sf\T, $ LVis{Sl,Tk) 


(AAZ) ^ Sl\T, LVis{Sl,Tk) 


k = k^ Sl\Tk<^LVis{Sl,Tk) 

(|44l|) A (ra A (ra ^ LVis{Sl,Tk) = Sl\Tk 


( |446[ ) ^ LVis{Sl,Tk)\x = [rk{x) Ak\ 

( |447l ) A (??) ^ LVis{Sl,Tk) is legal 
(448) => Tk in Sf is last-use legal in 

(420) A (4231 A (4301 a (4391 a (449) Pf is final-state last-use opaque 


Let P® be a prefix s.t. Pg = P® • [rk{x) 0]. 


(432) 

(433) 

(434) 

(435) 

(436) 

(437) 

(438) 

(439) 

(440) 

(441) 

(442) 

(443) 

(444) 

(445) 

(446) 

(447) 

(448) 

(449) 

(450) 

□ 
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Proof. 


let Cl = Compl{Pl) = P| • [reSj{Aj),res^{Aj)] 
let Si = elm ■ Cl\T, ■ Cl\Tk 

c9 _ /^9 

*^2 — ^2 

real time order <p|= {Ti <p9 T^} 

real time order <s|= {T* <59 Tj,T^ <59 Tfc.Tj <59 T^} 
(454) A (455) =^<g9^<p9 
i = i^ Sl\T, c LVis{Sl,Ti) 

T, <s9 T, Sl\T, $ LVis{Sl,T,) 

T, <s9 Tk Sl\Tk $ LVis{Sl,Ti) 

LVis{Sl,Tf) = Sl\T, 
oki\ 


(457) A (458) A (459) 


(460) 


LVis{Sl,Ti)\x = \wi{x)\ 
di^ A (U ^ LVis{Sl,Tf) is legal 
(462) Ti in is last-use legal in S! 

Wi {x) 1 ^ oki is closing write on x in Ti = 


T is decided on x in Sl 


T, <s9 T, A (|4^ ^ Sl\T, c LVis{Sl,T,) 
j = j ^ Sl\T, ^ LVis{SlT,) 

T, <s9 Tk Sl\Tk $ LVis{Sl,T,) 

( [4^ A (|^ A LVis{Sl,Tj) = Sim ■ Sl\Tj 

(468) ^=> LVis{Sl,Tj)\x = [wi{x)l —» oki,rj{x) 
di^ A d^ ^ LVis{Sl,Tj) is legal 
(470) Tj in S! is last-use legal in Sl 


1, Wj{x)2 okj] 


m <si Tfc A (|4^ ^ slim c LVtsiSl,Tk) or Sl\m $ LVis{SlTk) 

( H ^ Sfm, $ LVis{SlTk) 

Wj(x)2 —> okj is closing write on x in Tj Tj is decided on x in Sl 
Tj <s9 Tk A (Q ^ SI]t, c LVis{Sl,Tk) or s(\Tj $ LVis{Sl,Tk) 

( M ^ st\T, $ LVis{SlTk) 

k = k^ Sl\Tk c LVis{Sl,Tk) 

di^ A d^ A d^ ^ LVis{Sl,Tk) = Sl\Tk 

di^ ^ LVis{Sl,Tk)\x = 0 

di^ A ([§ ^ LVis{Sl,Tk) is legal 

(480) => Tk in Sl is last-use legal in Sl 

(453) A (456) A (463) a (471) a (481) P| is final-state last-use opaque 


(451) 

(452) 

(453) 

(454) 

(455) 

(456) 

(457) 

(458) 

(459) 

(460) 

(461) 

(462) 

(463) 

(464) 

(465) 

(466) 

(467) 

(468) 

(469) 

(470) 

(471) 

(472) 

(473) 

(474) 

(475) 

(476) 

(477) 

(478) 

(479) 

(480) 

(481) 

(482) 

(483) 
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□ 


Let Pi be a prefix s.t. Pg = P| • [reSj{okj), rk{x) —> 0]. 
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Proof. 


let Ci = Compl{P^) = Pf ■ [reSj{Aj),res,.{Aj)] 
let Si = elm ■ Cl\T, ■ Cl\Tk 

c9 _ /^9 

*^3 — ^3 

real time order <p|= {Ti <p9 T^} 

real time order <s|= {T^ <59 Tj,T^ <59 Tk,Tj <59 T^} 
(487) A (488) =xig9^<ip9 
i = i^ Sl\T, c LVis{Sl,Ti) 

T, <s9 T, Sl\T, $ LVis{SlTi) 

T, <s9 Tk Sl\Tk $ LVis{Sl,Ti) 

di^ A (|^ A LVis{Sl,Ti) = Sl\T, 

(493) ^=> LVis{Sl,Ti)\x = [wi{x)l oki] 
di^ A (U ^ LVis{Sl,Tf) is legal 
(495) Ti in S! is last-use legal in S'! 

Wi {x) 1 ^ oki is closing write on x in Ti => 

' ' s(\T,<^LVis{SlT,) 


Ti is decided on x in S! 


^Sl ^ (497) 
j = j ^ Sl\T, ^ LVtsiSlT,) 

T, <S9 Tk Sl\Tk $ LVisiSlT,) 

LVis{SlT,) = sf\T, ■ Sl\T, 

oki, rj{x) 


(498) A (499) A (500) 


( |501[ ) ^ LVis{Sl,Tj)\x = [wi{x)l 
d^ A d^ ^ LVis{Sl,Tj) is legal 
(503) Tj in Sl is last-use legal in Sl 


l,Wj{x)2 Aj\ 


Sl\Ti c LVis{Sl,Tk) or 5f|r, $ LVis{Sl,Tk) 


Tj is decided on x in S! 


^Sl ^ (497) 

( H ^ Sfmi $ LVis{Sl,Tk) 

Wj{x)2 —> okj is closing write on x in Tj 

T, <S9 Tk A ^ Sfm, c LVis{Sl,Tk) or 5||T, $ LVis{Sl,Tk) 

( H ^ sf\T, $ LVis{Sl,Tk) 

k = k^ Sl\Tk c LVis{Sl,Tk) 

dso^ A (1^ A ([ 5 ^ ^ LVis{Sl,Tk) = Sl\Tk 

dsnj ) ^ LVis{Sl,Tk)\x = 0 

dsi^ A ([§ ^ LVis{Sl,Tk) is legal 

(513) => Tk in sl is last-use legal in Sl 

(486) A (489) A (496) a (504) a (514) is final-state last-use opaque 


(484) 

(485) 

(486) 

(487) 

(488) 

(489) 

(490) 

(491) 

(492) 

(493) 

(494) 

(495) 

(496) 

(497) 

(498) 

(499) 

(500) 

(501) 

(502) 

(503) 

(504) 

(505) 

(506) 

(507) 

(508) 

(509) 

(510) 

(511) 

(512) 

(513) 

(514) 

(515) 

□ 


72 










































Let P 4 be a prefix s.t. Hg = ■ [wj{x)2 okj, rk{x) 0]. 

Lemma 52. Pf is final-state last-use opaque. 

Proof. 

let cl = Compl{Pl) = PI ■ [reSj{Aj),resj^{Aj)\ 
let Si = Cl\T, ■ Cl\T, ■ Cl\Tk 

c9 _ /^9 

O 4 — O 4 

real time order <p9= {Ti <p9 Tk} 

real time order <59= {Ti <59 Tj,T^ <59 Tk,Tj <59 Tk} 

( [^ A ( |^ ^<g 9 C<p 9 

z = i ^ Sl\T, ^ LVis{Sl,T,) 

T, <si Tj Sl\T, $ LVis{Sl,Ti) 

T, <s9 Tk Sl\Tk $ LVis{Sl,Tf) 

( [5^ A ([5^ A ([ 5 ^ ^ LVis{Sl,Tf) = Sl\T, 

(525) LVis{Sl^Ti)\x = [wi(a;)l ^ oki\ 

( [ 52 ^ A (H ^ LVis{Sl,Ti) is legal 
(527) Ti in S'! is last-use legal in Sl 

Wi{x)l oki is closing write on x in Ti Ti is decided on x in Sl 

T, <s9 Tj A (g ^ Sl\T, c LVis{Sl,Tj) 
j = j ^ Sl\T, ^ LVzs{Sl,T,) 

Tj <s9 Tk Sl\Tk $ LVis{SlT,) 

_ _ LVis{St Tj) = 5||r, • Sl\Tj 

LVis{Sl,Tj)\x = [wi{x)l oki,rj{x) 1] 


(530) A (531) A (532) 


( |533[ ) 

([54^ A (|4| ^ LVis{Sl,Tj) is legal 


(535) 


Tj in is last-use legal in S'! 


(516) 

(517) 

(518) 

(519) 

(520) 

(521) 

(522) 

(523) 

(524) 

(525) 

(526) 

(527) 

(528) 

(529) 

(530) 

(531) 

(532) 

(533) 

(534) 

(535) 

(536) 

(537) 
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T, <s9 Tk A (5291 ^ Sl\T, c LVis{Sl,Tk) or Sl\T, $ LVis{Sl,Tk) 


(5381 ^ 5||T, $ LVts{SlTk) 


!j{x)2 —* okj is closing write on x in Tj 


Tj is decided on x in Sf 


Tj <s9 n A (5401 ^ Sl\Tj c LVis{SlTk) or 5||T, $ LVis{SlTk) 


(^ ^ Sl\T, $ LVisiSln) 
k = k ^ Sl\Tk ^ LVisiSln) 

( 53^ A (1^ A (1^ ^ LVis{Sl,Tk) = Sl\Tk 
( 544| ^ LVis{Sl,Tk)\x = 0 
( ^ A (|§ ^ LVis{Sl,Tk) is legal 
(5461 Tk in S'! is last-use legal in Sf 


(538) 

(539) 

(540) 

(541) 

(542) 

(543) 

(544) 

(545) 

(546) 

(547) 

(548) 


(518) A (521) A (528) a (536) a (547) is final-state last-use opaque 


Let P| be a prefix s.t. Hg = P^ ■ [startk, Wj{x)2 okj, rk{x) 
Lemma 53. P® is final-state last-use opaque. 

Proof. 


P^ = Pg A Lemma 


28 


0 ], 


Let Pp be any prefix of Pf. 

Lemma 54. P® is final-state last-use opaque. 
Proof. 


Hi = PI ■ R A Corollary^^^ PI is last-use plague 

Pi = Pi A (S 


Pp is last-use lopaque 
(552) => Pp is final-state last-use lopaque 


(549) 

□ 


(550) 

□ 


(551) 

(552) 

(553) 

□ 


Lemma 55. Hg is last-use opaque. 


Proof. Since, from Lemmas 51 ■ 54 all prefixes of Hg are final-state last-use opaque, then by 
Def. Hg is last-use opaque. □ 

Corollary 10. Any prefix of Hg is last-use opaque. 
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starti 




-D 


ri(x) — 
o-a-D- 

T^ 


tryC^ 

-Q - 


^Ci 


startj Wj{x)2 tryCj ~^Cj 
o-a-D-a-- 0 

Tj 

startk rk{x) ^0 Wk{z)S tryCj^ Ak 

o-a-D-a-D-0-D 

Tk 


Ti 


starti ri{x) —»2 

o- 0 -D- 


ri(y) ^0 

-0-D- 


n(z)3 tryCi^Ai 
-o 


Figure 37: TMSl history example HU. 


B Property Comparison 

VWC is incomparable to last-use opacity. 


Lemma 56. There exists a last-use-opaque history H that is not virtual world consistent. 

sketch. Since, as an extension of by Lemmalast-use opacity supports early release, then 
by Def. and (by Def. from Lemma 55 there exists some last-use-opaque history where 
some transaction reads from a live transaction and aborts. Since, by Theoremj^VWC, does 
not support aborting releasing transactions, then, by the same definitions, such a history is 
not VWC. Hence a history with a transaction releasing early may be last-use-opaque but 
not VWC. □ 


Theorem 17. There exists a virtual world consistent history H that is not last-use-opaque. 

sketch. Since each transaction in a VWC history can be explained by a different causal past 
from other transactions, it is possible that in a correct VWC history transactions do not 
agree on the order of operations in the sequential witness history. However, in order for H 
to to be last-use-opaque the legality of transactions needs to be established using a single 
sequential history with a single order of operations. Thus, it is possible for a VWC history 
not to be last-use-opaque. □ 

Since TMSl is incomparable to last-use opacity. 

Theorem 18. There exists a last-use-opaque history H that is not TMSl. 

sketch. Since, as an extension of by Lemmalast-use opacity supports early release, then 
by Def. and there exist histories that are last-use-opaque where some transaction reads 
from a live transaction. Since, by TheoremTMSl, does not support early release, then, 
by the same definitions, histories containing early release are not TMSl. Hence a history 
with a transaction releasing early may be last-use-opaque but not TMSl. □ 


Theorem 19. There exists a TMSl history H that is not last-use-opaque. 


sketch. Let history H be the history presented in Fig. 37 In [lU (Fig. 6 therein) the authors 
show that the history satisfies TMSl. The same history is not last-use opaque. Note that 
if Vis{S,Ti) is to be legal, in any S equivalent to H, Ti <s Tj, because Ti reads 0 from x 
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starti 


T, 


O 


n(z)0 Wi{x)l n{y)0 i«i(y)l tryCi^Ci 

-o -@-^-o—-@- o 

start j ^rj{x)l Wi{x)2 tryCj^Cj 



Figure 38: Last-use-opaque history that does not satisfy elastic opacity. 


and Tj writes 2 to x (and commits). In addition, Tj <s Ti, because T; reads 2 from x and 
Tk <s Ti, because T; reads z from Tk- Then, by extension Ti <s Tj <s Ti. However, note 
that in any S it must be that Ti <s Ti, because Tj reads y from Ti, which is a contradiction. 
Thus, H is not last-use opaque. □ 

TMS2 is strictly stronger than last-use opacity. 

Proposition 1. All TMS2 histories are last-use-opaque. 

sketch. The authors of m believe (but do not demonstrate) that all opaque histories satisfy 
TMS2. If this is the case, then, since all opaque histories are last-use-opaque (Lemma |^, 
then it is true that all last-use-opaque histories satisfy TMS2. Thus, we believe the propo¬ 
sition is true, pending a demonstration that all opaque histories satisfy TMS2. □ 

Last-use Opacity and elastic opacity are incomparable. 

Lemma 57. There exists an elastic opaque history H that is not last-use-opaque. 

sketch. Since elastic opaque histories may not be serializable m, and since, as all last-use- 
opaque histories trivially require serializability then some elastic opaque histories are not 
last-use-opaque. □ 

Lemma 58. There exists a last-use-opaque history H that is not elastic opaque. 


sketch. Let history H be the history presented in Fig.|^ It should be straightforward to see 
that H is last-use-opaque for an equivalent sequential history S = T[\Ti ■ H\Tj. Operations 
on 0 are always justified in any sequential equivalent history since they are all within Ti and 
their effects are not visible in Tj. The read operation on y is expected to read 0 since it is 
not preceded in S by any write, and it does read 0. Thus operations on y and z will not 
break legality of either Ti or Tj. With that in mind, the history can be shown to be last-use 


opaque by analogy to Lemma 21 

On the other hand, let Ti be an elastic transaction. The only possible well-formed 
cut of H\Ti is Ci = {[r(z)0, w(x)l, r(?/)0, M;(y)l]}. (In particular, the following cut is 
not well-formed, since w{x)l and w{y)0 are in two different subhistories of the cut: C) = 
{[r(z)0, w;(x)l], [r(y)0, w(?/)l]}). Let fc{H) be a cutting function that applies cut C. Then, 
since the cut contains only one subhistory, it should be straightforward to see that fc{H) = 
H. Then, we note that H contains an operation in H\Tj that reads the value of x from H\Ti 
and Ti is live. That means that in the prefix P oi H s.t. H = P ■ \tryCi Ci, tryCj Cj] 
both transactions will be aborted in any completion of P, so for any sequential equivalent 
history S Vis{S,Ti) will not contain S\Tj, since either Tj is aborted in any S. Therefore 
Vis{S,Ti) will not justify reading 1 from x and will not be legal, causing P not to be final 
state opaque (Def. [^, which in turn means that H is not opaque (Def. [^. □ 
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T, 


starti 
o - 


Wi{x)l tryC^^Ci 



Tk 


start j 



r-kiy)3 tryC^ 

-5-o 

Wj(x)2 /ini(y)?, tryCj^Cj 
-6-o 




Figure 39: ACA history that does not satisfy elastic last-use opacity. 


Last-use opacity is strictly stronger than recoverability. 
Lemma 59. Any last-use-opaque history H is recoverable. 


sketch. Let us assume that H is not recoverable. Then there must be some transactions Ti 
and Tj s.t. T„- reads from Ti and then T,- commits before T^. By analogy to Lemma 25 


such a history will contain a prefix P where any completion will contain an aborted Ti and 
a committed Tj, so for any equivalent sequential history S Vis{S,Tj) will not contain S\Ti. 
Since Ti reads from Ti then such Vis{S, Tj) will not be legal, so by Def. 21 T is not last-use 
opaque and thus, by Def. H is not last-use opaque, which is a contradiction. □ 


ACA is incomparable to last-use opacity. 


Lemma 60. There exists a last-use-opaque history H that does not avoid cascading aborts. 

sketch. Lemma |21| demonstrates that Hi is last-use-opaque. However, since Ti reads from 
Tj in Hi and rj(x) v <Hi tryCi —* Ci the history is not ACA, since it contradicts 
Def. M □ 


Lemma 61. There exists an ACA history H that is not last-use-opaque. 


sketch. The history in Fig. 39 is shown to be ACA in [4]. However, note, that Compl{H) = 
H, and given any sequential S = Compl{H) Tj, Ty. must follow both Ti and Tj, in S because 
Tk reads form both transactions. Since Ti <2 Tj and Ti <2 Tk, then Ti must precede both 
other transactions in S. Hence, S = H\Ti ■ H\Tj ■ H\Tk, so Vis{S,Tk) = S and therefore 
Vis{S,Tk) is illegal because rk{x) ^ 1 is preceded in Vis{S,Tk)\x by rk{x) -^2. □ 

Strictness and last-use opacity are also incomparable. 

Theorem 20. There exists a last-use-opaque history H that is not strict. 


sketch. Since any strict history is also ACA [3], and since Lemma 60 shows that not all 
last-use-opaque histories are ACA, then not all last-use-opaque histories are strict. □ 


Theorem 21. There exists a strict history H that is not last-use-opaque. 


this history is not last-use-opaque. □ 

Rigorousness is strictly stronger than last-use opacity. 


sketch. The history in Fig. 39 is shown to be strict in [4]. However, as we show in Lemma 61 
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Lemma 62. Any rigorous history H is last-use-opaque. 

sketch. Since [1] demonstrates that rigorous histories are opaque, and since we show in 
Lemma that opaque histories are also last-use-opaque, then all rigorous histories are 
last-use-opaque. □ 


Live opacity is stronger than last-use opacity. 

Lemma 63. Any live opaque history H is last-use-opaque. 

sketch. Since H is live opaque there exists a sequential history S that justifies serializability 
of H and an extension S' of S where if transaction Ti is not in S then it is replaced in S' 
by T?'~ containing only non-local reads. S' is legal and preserves the real-time order of H 
(accounting for replaced transactions). In addition, from Theorem 11 no transaction in H 
reads from a live transaction (in any prefix of H). Therefore, since S' is legal, any read 
operation op^ = ri(x) —* v in H that is preceded Wj(x)v u in H, Tj is committed in S 
and is included in S' in full. 

Let S" be a sequential history constructed by replacing the operations removed to create 
S' where ii Ti e H and Ti | S' then Ti is aborted in S". S" preserves the real time order 
of H and S" = H. Note that, since S' is legal, if some write op'" is in S" and not in S', 
then there is no non-local read operation op" reading the value written by op'". Hence any 
operation reading the value written by op'" is local, and since all local reads in transactions 


that are replaced in S' read legal values (by Def. 12), then all reads reading from any op^ 
read legal values in S". Since S' is legal, then all reads reading from transactions that are in 
S read legal values in S'. Since S" = H, then these read and write operations also read legal 
values in S". Because of this, and since no transaction reads from another live transaction, 
Vis{S",Ti) will be legal for any transaction in S". In addition, LVis{S",Ti) will be legal 
for any aborted transaction in S". Therefore any live opaque H will be final state last-use 
opaque. Since any prehx of H is also live opaque, then any prefix will also be final-state 
last-use opaque, hence H is opaque. □ 


C /3—last-use opacity 

Definition 26 (/3-Closing Write Invocation). Given a program P, a set of processes H 
executing P and a history H s.t. H ^ £(P,H), i.e. H e an invocation inVi{w{x)v) is 

the closing write invocation on some variable x by transaction Ti in H, if for any history 
H' e for which H is a prefix (i.e., H' = H ■ R) there is no operation invocation inv' s.t. 
inVi{w{x)v) precedes inv' in H'\Ti where (a) inv' = inVi{w{x)u) or (b) inv' = inVi{tryA). 

Definition 27 (/3-Closing Write). Given program P, a set of processes H executing P and 
history H s.t. H ^ f (P, H), an operation execution is the closing write on some variable x 
by transaction Ti in H if it comprises of an invocation and a response other than Ai, and 
the invocation is the /3-closing write invocation on x by Ti in H. 

Definition 28 (Transaction /3—Decided on x). Given a program P, a set of processes H 
and a history H s.t. H ^ f(P,n), we say transaction R e H /3-decided on variable x in H 
iff H\Ti contains a complete write operation execution Wi{x)v oki that is the j5-closing 
write on x. 
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Given some history i7, let be a set of transactions s.t. Ti e iff there is some 
variable x s.t. Ti /3-decided on x in H. 

Given any Ti e H, H\^Ti is the longest subsequence of H\Ti s.t.: 

a) H\^Ti contains starti — > u, and 

b) for any variable x, if Ti /3-decided on x in H, then H\^Ti contains {H\Ti)\x. 

In addition, H\^Ti is a sequence s.t. H\^Ti = H\^Ti ■ [tryCi —> Ci\. 

Given a sequential history S s.t. S = H, PLVis{S,Ti) is the longest subhistory of S, s.t. 
for each Tj e S: 

a) S\Tj c pLVis{S,Ti) ii i = j or Tj is committed in S, or 

b) S\^Tj c f3LVis{S,Ti) if Tj is not committed in S but Tj e T^. 

Given a sequential history S and a transaction Ti e S, we then say that transaction Ti 

is P-last-use legal in S if j5LVis{S,Ti) is legal. 

Definition 29 (Final-state /3-Last-use Opacity). A finite history H is final-state (3-last-use 
opaque if, and only if, there exists a sequential history S equivalent to any completion of H 
s.t., 

a) S preserves the real-time order of H, 

b) every transaction in S that is committed in S is legal in S, 

c) every transaction in S that is not committed in S is (3-last-use legal in S. 

Definition 30 (/3-Last-use Opacity). A history H is (3-last-use opaque if, and only if, every 
finite prefix of H is final-state j3-last-use opaque. 

D SVA Correctness Proof 

Since the values used within writes are under the control of the program (rather than SVA) 
we simply assume that they are within the domain of the variables. 

Assumption 1 (Values Within Domain). For any transaction Ti in any SVA history H 
given variable x with the domain o/D, if Wi(x)v —> m e H\Ti, then z; e D. 

Definition 31 (Direct Precedence). For operations opi, opj G FI, opj -^h opi iff opj <h 
op^ and $opj. e H s.t. op^ <h opf. <h opi. 

Definition 32 (Operation Execution Conditional). Given predicate P and operation op 
P ^ op denotes that P is true only if op executes. 

Definition 33 (Operation Execution Converse). Given predicate P and operation op P ^ 
op denotes that op executes only if P is true. 

Let there be any P,n, iJ \= £l(P,n), opi G H\Ti. 

Definition 34. opi is closing access on x in Ti, denoted opi = dpf if both: 
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a) opj^ is closing read on x in Ti or op^ is closing write on x in Ti, and 

b) $op^ e H s.t. op^ <H op'^ and op'^ is closing read on x in Ti or op'i is closing write on 
X in Ti. 


Let there be any P, H, iJ \= £(P, H), opi e H\Ti, opi 


n{x) V, 
Wi{x)v oki. 


Lemma 64 (Access Condition). lv(a:) = pVj(a;) — 1 ^ opi- 

Proof. Condition at line [T^ dominates access at line[T7| □ 

Lemma 65 (Abort Condition). ltv(a;) = pVj(a:) — 1 ^ reSj(Ai). 

Proof. Access condition at line dominates dismiss at line in procedure abort for each 
variable. Hence, all variables must pass line [^before abort concludes. □ 

Lemma 66 (Commit Condition). ltv(a;) = pVj(a;) — 1 ^ reSj(C)). 

Proof. By analogy to Lemma |65l □ 


Lemma 67 (Early Release). If opi = dpf then lv{x) = pVj(a:) ^ opj. 


Proof. lv(a;) can be set by Ti at line 21 and at line 58 The former is set during the last 
access on some x in Tj (line [T^ dominates line 21). The latter is set during commit, which 
means that if any closing access was present, it was executed prior to commit. □ 


Let ri = 


|res,(Ai), 

\res^{Ci). 


Lemma 68 (Release). If $ op'i e H\Ti s.t. op'i = dpf and x e ASet(Ti) then lv(a;) = 
pvi(a;) ^ n. 


Proof. If op'i is not closing access then line 19 will not be passed, so only assignment of 
lv(a:) is in line 58 which execute only during commit or abort. □ 


Lemma 69 (Terminal Release). If x e ASet{Ti) then lv(a;) = pVj(a;) ^ ri. 


Proof. ltv(a;) can be set only in line 31 or line |43[ which are part of abort and commit, 
respectively. □ 


Let there be any H, Ti e H, Tj e H, opi e HfTi, opi = ri{x) 
opj = Wj{x)v okj. 


u, opj G H\Tj, 


Lemma 70 (No Buffering). If opj -^h\x oPi and not opj <h '>^eSj{Aj) <h opi then u = v. 
Lemma 71 (Revert On Abort). If opj -^h\x oPi and op^ <h T^^s^{Aj) <h opi then u ^ v. 


Proof. If abort is executed then the restore procedure is executed for all x 6 ASet{Ti). Thus, 
line 63 restores x to value v' which is acquired before the any operation on x is executed by 
Ti, hence v' 7^ v, so u 7^ v. □ 


Let H\start be a subhistory of H that for each Tj G H contains only the operation startj. 
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Lemma 72 (Consecutive Versions). If x e ASet{Ti) n ASet{Tj) and inv^{starti) -^H\start 
inv^{startj) then pVj(x) — 1 = pVj(x). 

Proof. If Ti returns at line for x then no Tj s.t. x e ASet{Tj) returns at lineuntil Ti 
executes line for x. Hence, Ti alone increments gv(x) at line and sets pVj(x) to the new 
value of gv(x). If starti -^H\start startj then Ti will return at linej^and Tj will return next. 
No other transaction will return at line between Ti and Tj. □ 

Lemma 73 (Unique Versions). If x e ASet{Ti) n ASet{Tj) then pVj(x) A pv (x). 


Proof. From Lemma [72} 


□ 


Lemma 74 (Monotonic Versions). If x e ASet{Ti) n ASet(Tj) and inVi{starti) <H\start 
inVi{startj) then pVj(x) < pv^(x). 

Proof. From Lemma [7^ Lemma □ 

Definition 35 (Version Order). Let <x be an order s.t. Ti <x Tj iff-pv^{x) < pv^(x). 
Lemma 75 (Forced Abort Condition), rvi(x) < cv(x) ^ reSj(Ai). 

Proof. Condition at line dominates abort at line Condition at line dominates 
abort at lineldOl 


□ 


Let there be any P, H, iJ ^ £(P, H), opi e [Ti, opi = 


n{x) - 
w^(x)i 


oki. 


Lemma 76. cv(x) < rvi(x) ^ opi. 

Proof. Condition at line [TS] dominates abort at line[T6| 

Lemma 77 (Current Version Early Release). If opi = dpf then cv(x) = rvi(x) 
Proof. By analogy to Lemma |67l 


op^■ 


□ 


□ 


Lemma 78 (Current Version Release). If$opi e II\Ti s.t. opi = dpf and x e ASet{Ti) 
then cv(x) = rvi(x) Ti. 


Proof. By analogy to Lemma |68l 
Lemma 79. cv(x) = rvi(x) ^ reSj(Ai). 
Proof. From Lemma and Lemma |78[ 


□ 


□ 


Let there be any P,n,i7 |= £’(P,H), Ti e H, Tj e iJ, opi e II\Ti, opj e II\Tj^ opi = 


n(x) ^ V, 
Wi{x)v —> oki, 


op. = 


rj{x) 
Wj (x) V 


okj- 


Lemma 80 (Access Order), pv-(x) < pv^(x) opi <h opj. 
Proof. From Lemma [64| and Lemma [74l 


□ 


Let there be any H, Ti e H, Tj e H, opi e II\Ti, opi = ri{x) u, opj e IIlTj 


opj = Wj{x)v okj. 

Let there be any P, H, iJ ^ £(P, H). 
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Lemma 81 (Access Prefix). If lv{x) = pvj{x) thenMTk ^ H s.t. pv^,(x) < pVj(a;) either 
res^{Ck) e H\Tk, reSf,{Ak) e H\Tk, or opf. e H\Tk. 

Proof. 


yTi,Tk e H s.t. pv;(x) = pvj,(a;) - 1 : 

Lemma [Ml lv(x) = pv^(a;) — 1 ^ op^. 

( 554[ ) A (5551 lv(x) = pv;(a;) ^ 

Lemma [67l lv(x) = pv;(a;) ^ opf 

Lemma [Ml lv(x) = pv;(x) ^ r where r = res^{Ai) or r = res^{Ci) 
A ( |558[ ) Ti is committed, aborted or decided on x 

Trivially extends for any Ti,Tk s.t. pv;(x) < pvj,(x). 


(554) 

(555) 

(556) 

(557) 

(558) 

(559) 

□ 


Lemma 82 (C). //Itv(x) = pvj(x) then VPfc e H s.t. pvj,(x) < pVj(x) either res^{Ck) 6 
H\Tk, or res^,(Afc) e H\Tk. 

Proof. 


VT/jTfc e H s.t. pv;(x) = pvj,(x) - 1 : 
Lemma IMl^^ Itv(x) = pvj,(x) — 1 - 

Itv(x) = pV;(x) ^ 

Itv(x) = pvj(x) 


( p0| A 

Lemma 1691^ 


- res^,{Ci) 

— OPk 

r where r = res^^Af) or r = res^{Ci) 


{ 563) => Ti is committed or aborted 


Trivially extends for any Ti,Tk s.t. pv;(x) < pvj,(x). 


(560) 

(561) 

(562) 

(563) 

(564) 

□ 


Let there be any H, Ti e H, Tj e H, opi e i7|Ti, opi = ri{x) u, opj e II\Tj, 
opj = Wj{x)v okj. 

Lemma 83 (Forced Abort). If x e ASet(Ti) n ASet{Tj) and reSj{Aj) e II\Tj and opi <h 
reSj{Aj) then reSj(Ai) e II\Ti. 

Proof. 


resJAj) G II\Tj a Lemma 
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cv(x) = pvjx ^ resJAj) 


Lemma 


74 


pv -(x) < pv,(x) 


(5651 A (566) cv(x) < pvix ^ res^(Aj) 

Lemma 76 cv(x) = rvi(x) ^ opi rvi(x) = pv^(x) 

(568) A (566) rvi(x) > pVj(x) 

(569) A (567) rvi(x) < cv(x) 

(570) rvi(x) < cv(x) ^ reSi(Ai) reSi(Ai) e HfTi 


Let there be any P,n,i7 |= f(P, 11), Ti e H, Tj e H, opi e HjTi, opj g 

ri{x) ^ V, _{rj{x)^v, 

Wi{x)v oki, ^ I Wj{x)v okj. 


(565) 

(566) 

(567) 

(568) 

(569) 

(570) 

(571) 

□ 

OPi = 
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Definition 36 (Completion Construction). He = Compl{H) s.t. e H, res^{Ck) ^ 
H\Tk resi^{Ak) e Hc\Tk 

Definition 37 (Sequential History Construction). Sh is a sequential history s.t. Sh = He 
and Ti <Hc '^j Tj and Ti <x Tj Ti <§^ Tj. 

Let there be any H, Ti e H, Tj e iL, opi e H\Ti, opi = ri{x) u, opj e H\Tj, 
opj = Wj{x)v okj. 

Lemma 84. IfTi reads x from Tj then Tj is committed in H or Tj is decided on x in H. 
Proof. 


Ti reads x from Tj opi = ri{x) v a op, = Wj{x)v 


oki A opj <H op^ 


Lemma 64 
Lemma 
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(5741 A Lemma 81 


^ lv(a;) = pv^(-)l ^ opi 
A opj <H op, pvj(a;) < pv,(a;) 

Tj is committed, aborted, or decided on x 


Let us assume that Tj is aborted: 


(572) 

(573) 

(574) 

(575) 


opi < reSj{Aj) : Lemma [72 
reSj{Aj) <H opi : Lemma 67 


Thus, Ti is committed or decided on x. 


V 7 ^ V contradiction 
lv(a;) = pv,^(^)op, A op, = dpf 


(576) 

(577) 

□ 


Corollary 11. If P is any prefix of H, then ifTi reads x from Tj in P then Tj is committed 
in P or Tj is decided on x in P. 

Lemma 85. IfTi reads x from Tj and Tj is committed in H then Tj is committed in H. 
Proof. 


Ti reads x from Tj opi = ri{x) v a opj = Wj{x)v oki a opj <h opi (578) 
Lemma [66l => ltv(a:) = pvj,(a;) — 1 ^ reSi{oki) (579) 

Lemma [80l a opj <h opi pv^{x) < pv^{x) (580) 

Lemma a (579) a (580) r e H\Tj where r = reSj{Aj) or r = reSj{Cj) (581) 
Lemma [83l^^ if reSj{Aj) G H\Tj then reSj{Aj) e H\Tj contradition (582) 

( [^ ^ reSiiAi) G £r|r, (583) 

□ 


Let there be any P, H, iJ ^ £(P, H), Ti e H, opi = ri{x) v, opi G H\Ti. 
Lemma 86. If reSi{Ci) G SH\Ti then ^opj = Wj{x)v —> okj G Vis{SH^Ti). 
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Proof, li i = j then trivially opj e Vis{SH,Ti). Otherwise: 


i j A Lemma FfOl 3Tj a op^ e Hc\Tj 

( [^ A LemmalMlA reSi(a) e Hc\Ti 3reSj(Q) e Hc\T^ 

Def.EZlA 1^ ^ reSj{Cj) e SH\Tj a T, 

ra ^ Sh\T, c Vis{Sh,T,) opj e Vis{Sh,T,) 


Lemma 87. = Wj{x)v okj e LVis{SH,Ti). 

Proof, li i = j then trivially opj e LVis{SH,Ti). Otherwise: 


(584) 

(585) 

(586) 

(587) 

□ 


i ¥= j A Lemma FZOl ^=> 3Tj a op^ e Hc\Tj 
(5881 A Lemma [84l a res^{Ci) e Hc\Ti => 


(588) 

either 3reSj{Cj) e Hc\Tj or 3opj e Plc\Tj 


Def.[37]A (5891 ^ reSj{Cj) e 5'ff|Tj a Tj T, 

( |590| ) ^ Sh\Tj c LVis{SH.Tf) op^ e LVis{Sh,T,) 
(g ^ e Sh\Tj a Tj T, 

([iiij) A SH\Tj c LVis{SH,Ti) opj e LVis{SH,T,) 


(589) 

(590) 

(591) 

(592) 

(593) 

□ 


Lemma 88. Given Sh o-nd any two transactions Ti,Tj G Sh s.t. there is an operation 
execution Wj{x)v okj G ShITj and ri(x) v e SnlTi then there is no operation 
Wk{x)u okk (executed by some e Sh) in Vis{SH,Ti) s.t. Wk{x)u —> okk precedes 
ri{x) V in Vis{SH,Ti) and follows Wj{x)v okj in Vis{SH,Ti). 


Proof. For the sake of contradiction, assume that op/. exists as specihed. 

If fc = i, then opj, <H\Ti oPi, which contradicts Lemma 70 (assuming unique writes). 
If A: = J, then from Lemma 


84 


Tj is either committed or decided on x in Sh- 


If T, 


commits, then op^ reading v contradicts Lemma 70 If Ti does not commit in P, then this 
contradicts Lemma l85] 

Otherwise, 3Tk G PI s.t. opj, G i7|Tfc from Lemma 84 Tj is either committed or decided 
on X in Sh and from Lemma 85 Tk is committed in H. Since Tfc commits, this contradicts 
Lemma [TO] □ 


Lemma 89. Given Sh o,nd any two transaction Ti, Tj G Sh s.t. there is an operation execu¬ 
tion Wj{x)v —> okj G SnlTj and ri{x) v e SnlTi then there is no operation Wk{x)u —> ofcfc 
(executed by some Tk G Sh) in LVis{SH,Ti) s.t. Wk{x)u okk precedes ri{x) v in 
Vis{SH,Ti) and follows Wj{x)v okj in Vis{SH,Ti). 

Proof. By analogy to Lemma |88l □ 

Lemma 90. Any SVA history H is final-state last-use opaque. 
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Proof. Given Sh, let Ti e Srr be any transaction that is committed in Sh- In that case, 


from Lemma 


86 


and Lemma |88[ every read operation execution ri{x) ^ v in Vis{SH,Ti) 
is preceded in Vis{SH,Ti) by a write operation execution Wj{x)v —> okj (for some Tj). In 
addition, from Assumption]^ every write operation execution Wi{x)v oki in Vis^Sn,Ti) 
trivially writes v e D. Therefore, for every variable x, Vis{SH,Ti)\x e Seq{x), so Vis{SH,Ti) 
is legal. Consequently Ti in Sh is legal in Sh- 

Given the same Sh, let Ti e Sh be any tra nsa ction that is not committed in Sh (so it is 


aborted in Sh)- From Lemma 


87 


and Lemma 


89 


every read operation execution ri(x) —» v 
in LVis{SH, Ti) is preceded in LVis^Sn, Ti) by a write operation execution Wj{x)v okj (for 
some Tj). In addition, from Assumption]^ every write operation execution Wi{x)v —> oki in 
LVis{SH, Ti) trivially writes v e D. Therefore, for every variable x, LVis{SH, Ti)\x G Seq{x), 
so LVis{SH,Ti) is legal. Thus, Ti in Sh is last-use legal in Sh- 

Since all committed transactions in Sh ar e le gal in Sh and since all aborted transactions 
in Sh are last-use legal in Sh, then, by Def. 21 H is final-state last use opaque. □ 


Theorem 22. Any SVA history H is last-use opaque. 


Proof. Since by Lemma any SVA history H is final-state last-use opaque, and any prefix 
P of iL is also an SVA history, then every prefix of H is also final-state last-use opaque. 
Thus, by Def. H is last-use opaque. □ 
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